¿Cómo evitar usar sudo cuando trabajas en / var / www?
173
Quiero dejar de usar sudocada vez que trabajo /var/www. ¿Cómo puedo hacer eso? Simplemente quiero poner todos mis sitios en este directorio y trabajar con ellos sin demasiado dolor.
Otra forma de obtener seguridad es continuar usándolo, sudo -u www-datapero restringirse en el sudoersarchivo para poder solo sudo www-data(y no sudo root). Ver serverfault.com/questions/295429/…
Simon Woodside
Respuestas:
250
La mayoría de las respuestas aquí no están escritas con la seguridad en mente. Es bueno tener la sensación de que correr sudocada vez no es muy sabio. Si hace un error tipográfico (por ejemplo, un espacio en blanco en un lugar incorrecto: sudo rm -rf / var/www/dir¡no lo ejecute! ), Podría tirar a la basura su sistema.
Nota: Comenzando con Apache 2.4.7 / Ubuntu 14.04, /var/wwwse ha movido a /var/www/htmlAjustar los comandos en esta respuesta en consecuencia.
chmod 777(sagarchalise): esto permite que cualquier persona con acceso a su sistema escriba en los directorios y archivos y, por lo tanto, permite al intruso ejecutar cualquier código bajo el www-datausuario
chgrp -R www-data $HOME(cob): esto permite www-dataleer o escribir cualquier archivo en el directorio de inicio. Esto no tiene en cuenta la regla de Privilegio Mínimo
chown -R $USER:$USER /var/www(kv1dr): a menos que el mundo tenga permisos de lectura /var/www, el servidor web que se ejecuta www-datano podrá leer (servir) los archivos. Si el archivo es un documento HTML simple accesible al público, puede que no sea un problema si el mundo puede leer el archivo. Pero si el archivo es un archivo PHP que contiene contraseñas, lo es.
NOTA : en las siguientes soluciones, he otorgado www-dataprivilegios de escritura. Sin embargo, /usr/share/doc/base-passwd/users-and-groups.txt.gzafirma:
www-data
Algunos servidores web se ejecutan como www-data. El contenido web no debe ser propiedad de este usuario, o un servidor web comprometido podría reescribir un sitio web. Los datos escritos por los servidores web serán propiedad de www-data.
Siempre que sea posible, no otorgue permisos de escritura al www-datagrupo. www-datasolo necesita poder leer los archivos para que el servidor web pueda servirlo. El único caso en el que se www-datanecesitan permisos de escritura es para directorios que almacenan cargas y otras ubicaciones que deben escribirse.
Solución 1
Agréguese al www-datagrupo y establezca el bit setgid en el /var/wwwdirectorio de modo que todos los archivos recién creados hereden también este grupo.
sudo gpasswd -a "$USER" www-data
Corrija los archivos creados previamente (suponiendo que usted sea el único usuario de /var/www):
(aún más seguro: utilizar 640o 2750manualmente y chmod g+w file-or-dirque tiene que ser escribible por el servidor web)
Solución 2
Cree un enlace simbólico para cada proyecto en su directorio de inicio. Digamos que su proyecto está ubicado en ~/projects/fooy desea que esté ubicado en /var/www/foo, ejecute:
sudo ln -sT ~/projects/foo /var/www/foo
Si su directorio de inicio no tiene un bit de ejecución (descender) establecido para other(por razones de seguridad), cambie el grupo a él www-data, pero configure solo el bit de ejecución (sin lectura / escritura). Haga lo mismo para la ~/projectscarpeta, ya que puede contener otros proyectos además de www. (No es necesario sudosi ha agregado previamente su usuario al www-datagrupo).
Ajuste el grupo para www-datael ~/projects/fooy permitir que el servidor web para leer y escribir a los archivos y directorios de archivos + y descender en los directorios:
Aún más seguro: use 640 y 2750 por defecto y manualmente archivos y directorios chmod que el usuario del servidor web debe poder escribir. El bit setgid debe agregarse solo si desea que ~/projects/fooel grupo pueda acceder a todos los archivos recién creados .
A partir de ahora, puede acceder a su sitio en http://localhost/fooy editar sus archivos de proyecto ~/projects/foo.
¿Qué opinas sobre una sesión www en una terminal sudo su www-data? Combinado con un indicador de color diferente, para que sea más obvio que es el shell de un usuario diferente, y una política siempre para poner el xterm correspondiente en, por ejemplo, el escritorio virtual 4, para que se acostumbre a él, a ¿evitar confusion?
usuario desconocido el
@user unknown: si hace todo bien en el terminal, ya que tiene una clara separación entre las cuentas de usuario. Pero no va a funcionar si usa un programa GUI como gedit. Nunca he investigado si ejecutar un programa GUI bajo otro usuario en la sesión actual es seguro o no, sería una pregunta interesante.
Lekensteyn 01 de
1
@imaginaryRobots: si iba a publicar diferentes soluciones para cada pregunta, Askubuntu estaría lleno de respuestas de tres líneas. Lo mantendré como está a menos que puedas convencerme de dividirlo.
Lekensteyn
1
@berbt setfacl -d u::rwX,g::rX /var/wwwtiene el divertido efecto de que el modo predeterminado se convierte en 0750 (o 0640) incluso si la máscara de usuario es cero. Puede ser una buena idea si desea evitar los archivos que se pueden escribir en todo el mundo, pero si /var/wwwel mundo ya no puede acceder a ellos, no es necesario.
Lekensteyn
1
¿Hay algún problema con la inversión del proceso en la solución 1? Con eso quiero decir, ¿ /var/www/app01tiene la propiedad app01:app01y luego el www-datausuario se agrega al app01grupo ? ¿O eso romperá algo?
Jack_Hu
9
En lugar de almacenar mis sitios web en / var / www, coloco enlaces allí a los sitios que se encuentran en mi carpeta de inicio. Puedo editar o agregar páginas libremente a mis sitios. Cuando estoy contento con los cambios, me dirijo a una empresa de hosting donde se vincula mi nombre de dominio.
Debería poder editar /var/www/archivos sin problemas.
La primera línea lo agrega al www-datagrupo, la segunda línea borra todos los archivos con propiedad desordenada, y la tercera lo hace para que todos los usuarios que son miembros del www-datagrupo puedan leer y escribir todos los archivos /var/www.
Esta es una muy mala idea para la seguridad y este consejo no debe seguirse, por razones explicadas en otras respuestas. Se supone que www-data es un grupo sin privilegios , sin acceso de escritura.
thomasrutter
5
No hacer
No establezca permisos de archivo en 777 (de escritura mundial)
Esta es una falla de seguridad significativa, especialmente si habilita las secuencias de comandos del lado del servidor, como PHP. Los procesos no privilegiados no deberían poder escribir en archivos que afectarían al sitio web o, en el caso de que se utilicen secuencias de comandos del lado del servidor, ejecutar código arbitrario.
No se agregue como miembro del grupo www-data y dele permisos de escritura
El propósito de ese grupo es que es un grupo sin privilegios en el que se ejecutan los procesos del servidor . Solo deberían tener acceso de lectura a los archivos del sitio web cuando sea posible, por los mismos motivos que los anteriores.
No cambie los permisos de los procesos de Apache.
Los procesos secundarios de Apache se ejecutan como www-datausuario y grupo de forma predeterminada, y esto no debe modificarse. Esta es solo una forma de no darles permiso de escritura al sistema de archivos.
En determinadas circunstancias, desea que sus scripts del lado del servidor puedan escribir en archivos, en cuyo caso solo esos archivos deben poder escribirse www-datay se debe tener cuidado para garantizar la seguridad.
Dos
Configure los archivos para que sean de su propiedad
Si usted es el único, o el habitual, en modificar ciertos archivos en el sitio web, entonces tiene mucho sentido simplemente tomar posesión de esos archivos. Establecer su propietario a <your username>.
No tiene que modificar los permisos del servidor para esto, ya que el servidor continuará obteniendo acceso de solo lectura incluso cuando los archivos sean de su propiedad.
Elija un lugar adecuado para alojar los archivos (usando DocumentRoot )
Si /var/wwwno tiene sentido, puede colocarlos en otro lugar. Si son específicos de su propio desarrollo o prueba, puede colocarlos en su directorio de inicio. O puede configurar algunos directorios en /srv.
Si desea dar acceso de escritura grupal , cree un nuevo grupo para tal fin
No reutilice un grupo de sistemas, porque estos están diseñados típicamente para tener el acceso que tienen actualmente, y no más, por razones de seguridad.
+1 Eso es lo que hago: cambiar la propiedad no de /var/wwwsí mismo, sino de los subdirectorios.
fkraiem
2
chmod in / var en www para permitir el acceso del propietario y chown para asegurarse de que lo posee. Probablemente una idea estúpida, pero definitivamente funcionaría.
No es una idea estúpida, es una idea sensata en cuanto a seguridad. Nota: No necesita (y no debe) cambiar los permisos de /var, solo /var/wwwy / o su contenido.
thomasrutter
1
Podrías iniciar una sesión www en una terminal por
sudo su www-data
Combinado con un indicador de color diferente *, para que sea más obvio que es el shell de un usuario diferente, y una política siempre para poner el xterm correspondiente (y el editor y demás) en, por ejemplo, el escritorio virtual 4, de modo que te acostumbras, para evitar confusiones.
*) Para una solicitud de color diferente con un carácter diferente, cree un archivo / etc / prompt como este:
# 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
y obtenerlo de, /etc/bash.bashrcpor ejemplo.
Como herramienta adicional para ayudar a la distinción, siempre puede editar sus archivos con un alias 'editar' o un enlace simbólico, que apunta, dependiendo de su identidad (taylor / www-data) a gedit o mousepad, vim o pico. O puede usar diferentes perfiles de editor, al menos en gedit puede establecer sus preferencias para texto negro sobre fondo blanco o texto blanco sobre fondo negro, por ejemplo.
Solo tengo una política de este tipo para trabajar como root, por lo que no estoy seguro de cuán bueno será para trabajar con www-data. Combinado con sesiones ssh para diferentes hosts, que tienen sus propios avisos, no evitó que me equivocara a veces, pero si sucede, me doy cuenta rápidamente de lo que está mal y rara vez sucede.
nota: el script de solicitud es en parte una copia de la página de manual de bash.
Esto funcionará y no (si se usa con cuidado) afectará negativamente la seguridad, pero puede no ser la solución más sencilla. Sin embargo, es una solución válida para algunas personas.
sudo -u www-data
pero restringirse en elsudoers
archivo para poder solosudo www-data
(y no sudo root). Ver serverfault.com/questions/295429/…Respuestas:
La mayoría de las respuestas aquí no están escritas con la seguridad en mente. Es bueno tener la sensación de que correr
sudo
cada vez no es muy sabio. Si hace un error tipográfico (por ejemplo, un espacio en blanco en un lugar incorrecto:sudo rm -rf / var/www/dir
¡no lo ejecute! ), Podría tirar a la basura su sistema.Nota: Comenzando con Apache 2.4.7 / Ubuntu 14.04,
/var/www
se ha movido a/var/www/html
Ajustar los comandos en esta respuesta en consecuencia.Ver:
¿Dónde ubicar mi sitio web local a partir de la versión 2.4.7 de apache2?
¿Por qué se ha movido el directorio apache2 www a / var / www / html?
Cambiar la raíz del documento predeterminada para el servidor HTTP
Malas ideas:
chmod 777
(sagarchalise): esto permite que cualquier persona con acceso a su sistema escriba en los directorios y archivos y, por lo tanto, permite al intruso ejecutar cualquier código bajo elwww-data
usuariochgrp -R www-data $HOME
(cob): esto permitewww-data
leer o escribir cualquier archivo en el directorio de inicio. Esto no tiene en cuenta la regla de Privilegio Mínimochown -R $USER:$USER /var/www
(kv1dr): a menos que el mundo tenga permisos de lectura/var/www
, el servidor web que se ejecutawww-data
no podrá leer (servir) los archivos. Si el archivo es un documento HTML simple accesible al público, puede que no sea un problema si el mundo puede leer el archivo. Pero si el archivo es un archivo PHP que contiene contraseñas, lo es.NOTA : en las siguientes soluciones, he otorgado
www-data
privilegios de escritura. Sin embargo,/usr/share/doc/base-passwd/users-and-groups.txt.gz
afirma:Siempre que sea posible, no otorgue permisos de escritura al
www-data
grupo.www-data
solo necesita poder leer los archivos para que el servidor web pueda servirlo. El único caso en el que sewww-data
necesitan permisos de escritura es para directorios que almacenan cargas y otras ubicaciones que deben escribirse.Solución 1
Agréguese al
www-data
grupo y establezca el bit setgid en el/var/www
directorio de modo que todos los archivos recién creados hereden también este grupo.Corrija los archivos creados previamente (suponiendo que usted sea el único usuario de
/var/www
):(aún más seguro: utilizar
640
o2750
manualmente ychmod g+w file-or-dir
que tiene que ser escribible por el servidor web)Solución 2
Cree un enlace simbólico para cada proyecto en su directorio de inicio. Digamos que su proyecto está ubicado en
~/projects/foo
y desea que esté ubicado en/var/www/foo
, ejecute:Si su directorio de inicio no tiene un bit de ejecución (descender) establecido para
other
(por razones de seguridad), cambie el grupo a élwww-data
, pero configure solo el bit de ejecución (sin lectura / escritura). Haga lo mismo para la~/projects
carpeta, ya que puede contener otros proyectos además de www. (No es necesariosudo
si ha agregado previamente su usuario alwww-data
grupo).Ajuste el grupo para
www-data
el~/projects/foo
y permitir que el servidor web para leer y escribir a los archivos y directorios de archivos + y descender en los directorios:Aún más seguro: use 640 y 2750 por defecto y manualmente archivos y directorios chmod que el usuario del servidor web debe poder escribir. El bit setgid debe agregarse solo si desea que
~/projects/foo
el grupo pueda acceder a todos los archivos recién creados .A partir de ahora, puede acceder a su sitio en
http://localhost/foo
y editar sus archivos de proyecto~/projects/foo
.Ver también
fuente
sudo su www-data
? Combinado con un indicador de color diferente, para que sea más obvio que es el shell de un usuario diferente, y una política siempre para poner el xterm correspondiente en, por ejemplo, el escritorio virtual 4, para que se acostumbre a él, a ¿evitar confusion?gedit
. Nunca he investigado si ejecutar un programa GUI bajo otro usuario en la sesión actual es seguro o no, sería una pregunta interesante.setfacl -d u::rwX,g::rX /var/www
tiene el divertido efecto de que el modo predeterminado se convierte en 0750 (o 0640) incluso si la máscara de usuario es cero. Puede ser una buena idea si desea evitar los archivos que se pueden escribir en todo el mundo, pero si/var/www
el mundo ya no puede acceder a ellos, no es necesario./var/www/app01
tiene la propiedadapp01:app01
y luego elwww-data
usuario se agrega alapp01
grupo ? ¿O eso romperá algo?En lugar de almacenar mis sitios web en / var / www, coloco enlaces allí a los sitios que se encuentran en mi carpeta de inicio. Puedo editar o agregar páginas libremente a mis sitios. Cuando estoy contento con los cambios, me dirijo a una empresa de hosting donde se vincula mi nombre de dominio.
fuente
Si hace que / var / www pueda escribirse por su grupo y se agregue al grupo, no tendrá que usar sudo mientras sea bastante seguro. Prueba esto:
Debería poder editar
/var/www/
archivos sin problemas.La primera línea lo agrega al
www-data
grupo, la segunda línea borra todos los archivos con propiedad desordenada, y la tercera lo hace para que todos los usuarios que son miembros delwww-data
grupo puedan leer y escribir todos los archivos/var/www
.fuente
No hacer
No establezca permisos de archivo en 777 (de escritura mundial)
Esta es una falla de seguridad significativa, especialmente si habilita las secuencias de comandos del lado del servidor, como PHP. Los procesos no privilegiados no deberían poder escribir en archivos que afectarían al sitio web o, en el caso de que se utilicen secuencias de comandos del lado del servidor, ejecutar código arbitrario.
No se agregue como miembro del grupo www-data y dele permisos de escritura
El propósito de ese grupo es que es un grupo sin privilegios en el que se ejecutan los procesos del servidor . Solo deberían tener acceso de lectura a los archivos del sitio web cuando sea posible, por los mismos motivos que los anteriores.
No cambie los permisos de los procesos de Apache.
Los procesos secundarios de Apache se ejecutan como
www-data
usuario y grupo de forma predeterminada, y esto no debe modificarse. Esta es solo una forma de no darles permiso de escritura al sistema de archivos.En determinadas circunstancias, desea que sus scripts del lado del servidor puedan escribir en archivos, en cuyo caso solo esos archivos deben poder escribirse
www-data
y se debe tener cuidado para garantizar la seguridad.Dos
Configure los archivos para que sean de su propiedad
Si usted es el único, o el habitual, en modificar ciertos archivos en el sitio web, entonces tiene mucho sentido simplemente tomar posesión de esos archivos. Establecer su propietario a
<your username>
.No tiene que modificar los permisos del servidor para esto, ya que el servidor continuará obteniendo acceso de solo lectura incluso cuando los archivos sean de su propiedad.
Elija un lugar adecuado para alojar los archivos (usando DocumentRoot )
Si
/var/www
no tiene sentido, puede colocarlos en otro lugar. Si son específicos de su propio desarrollo o prueba, puede colocarlos en su directorio de inicio. O puede configurar algunos directorios en/srv
.Si desea dar acceso de escritura grupal , cree un nuevo grupo para tal fin
No reutilice un grupo de sistemas, porque estos están diseñados típicamente para tener el acceso que tienen actualmente, y no más, por razones de seguridad.
fuente
Es así de simple. No necesita habilitar apache 'UserDir' (no recomendado) ni desordenar con grupos 'www-data' (grupo apache en el caso de Fedora)
Simplemente cree su directorio de proyecto dentro
/var/www/html
Luego simplemente muestra el directorio del proyecto a tu usuario.
Ahora puede comenzar a trabajar en su carpeta de proyecto como usuario habitual con cualquier editor, IDE de su elección. No hay más sudos :)
fuente
/var/www
sí mismo, sino de los subdirectorios.chmod in / var en www para permitir el acceso del propietario y chown para asegurarse de que lo posee. Probablemente una idea estúpida, pero definitivamente funcionaría.
fuente
/var
, solo/var/www
y / o su contenido.Podrías iniciar una sesión www en una terminal por
Combinado con un indicador de color diferente *, para que sea más obvio que es el shell de un usuario diferente, y una política siempre para poner el xterm correspondiente (y el editor y demás) en, por ejemplo, el escritorio virtual 4, de modo que te acostumbras, para evitar confusiones.
*) Para una solicitud de color diferente con un carácter diferente, cree un archivo / etc / prompt como este:
y obtenerlo de,
/etc/bash.bashrc
por ejemplo.Como herramienta adicional para ayudar a la distinción, siempre puede editar sus archivos con un alias 'editar' o un enlace simbólico, que apunta, dependiendo de su identidad (taylor / www-data) a gedit o mousepad, vim o pico. O puede usar diferentes perfiles de editor, al menos en gedit puede establecer sus preferencias para texto negro sobre fondo blanco o texto blanco sobre fondo negro, por ejemplo.
Solo tengo una política de este tipo para trabajar como root, por lo que no estoy seguro de cuán bueno será para trabajar con www-data. Combinado con sesiones ssh para diferentes hosts, que tienen sus propios avisos, no evitó que me equivocara a veces, pero si sucede, me doy cuenta rápidamente de lo que está mal y rara vez sucede.
nota: el script de solicitud es en parte una copia de la página de manual de bash.
fuente