Comment éviter d'utiliser sudo lorsque vous travaillez dans / var / www?

163

Je ne veux plus utiliser sudo à chaque fois que je travaille dans /var/www . Comment puis je faire ça? Je veux simplement mettre tous mes sites dans ce répertoire et travailler avec eux sans trop de peine.

    
posée TaylorOtwell 01.06.2011 - 05:43
la source

8 réponses

230

La plupart des réponses ne sont pas écrites dans un souci de sécurité. Il est bon de penser que lancer sudo à chaque fois n’est pas très sage. Si vous faites une faute de frappe (par exemple ( ne vous exécutez pas ) sudo rm -rf / var/www/dir ), vous risquez de mettre votre système à la corbeille.

Remarque: Depuis Apache 2.4.7 / Ubuntu 14.04, /var/www a été déplacé vers /var/www/html . Ajustez les commandes de cette réponse en conséquence.

Voir:

Mauvaises idées:

  • chmod 777 (sagarchalise) - cela permet à toute personne ayant accès à votre système d'écrire dans les répertoires et les fichiers, permettant ainsi à l'intrus d'exécuter n'importe quel code sous www-data user
  • chgrp -R www-data $HOME (cob) - cela permet à www-data de lire ou d'écrire tous les fichiers du répertoire de base. Cela ne tient pas compte de la règle du moindre privilège
  • chown -R $USER:$USER /var/www (kv1dr) - à moins que le monde ne dispose d'autorisations de lecture sur /var/www , le serveur Web exécuté sous www-data ne pourra pas lire (servir) les fichiers. Si le fichier est un document HTML ordinaire accessible au public, le problème peut être résolu si le monde peut lire le fichier. Mais si le fichier est un fichier PHP contenant des mots de passe, il l’est.

REMARQUE : dans les solutions ci-dessous, j'ai accordé des privilèges d'écriture à www-data . Cependant, /usr/share/doc/base-passwd/users-and-groups.txt.gz indique:

www-data

Some web servers run as www-data. Web content should not be owned by this user, or a compromised web server would be able to rewrite a web site. Data written out by web servers will be owned by www-data.

Dans la mesure du possible, ne pas accorder des autorisations d'écriture au groupe www-data . www-data doit uniquement pouvoir lire les fichiers pour que le serveur Web puisse les servir. Le seul cas où www-data a besoin d'autorisations en écriture concerne les répertoires contenant les téléchargements et les autres emplacements à écrire.

Solution 1

Ajoutez-vous au groupe www-data et définissez le bit setgid sur le répertoire /var/www de sorte que tous les fichiers nouvellement créés héritent également de ce groupe.

sudo gpasswd -a "$USER" www-data

Corrigez les fichiers créés précédemment (en supposant que vous soyez le seul utilisateur de /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 {} \;

(encore plus sûr: utilisez 640 ou 2750 et manuellement chmod g+w file-or-dir qui doit être inscriptible par le serveur Web)

Solution 2

Créez un lien symbolique pour chaque projet vers votre répertoire personnel. Supposons que votre projet se situe à ~/projects/foo et que vous souhaitez le placer à /var/www/foo , exécutez:

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

Si votre répertoire personnel n’a pas de bit d’exécution (descendant) défini pour other (pour des raisons de sécurité), remplacez-le par www-data , mais définissez le bit d’exécution uniquement (non lire écrire). Faites de même pour le dossier ~/projects car il peut contenir d’autres projets que www. (Vous n'avez pas besoin de sudo si vous avez déjà ajouté votre utilisateur au groupe www-data .)

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

Définissez le groupe sur www-data sur ~/projects/foo et autorisez le serveur Web à lire et à écrire dans des fichiers et des fichiers + répertoires et à descendre dans les répertoires:

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

Encore plus sûr: utilisez 640 et 2750 par défaut et manuellement les fichiers et répertoires chmod devant être accessibles en écriture à l'utilisateur du serveur Web. Le bit setgid ne doit être ajouté que si vous souhaitez que tous les fichiers nouvellement créés dans ~/projects/foo soient accessibles au groupe.

Vous pouvez désormais accéder à votre site à l'adresse http://localhost/foo et modifier vos fichiers de projet dans ~/projects/foo .

Voir aussi

réponse donnée Lekensteyn 01.06.2011 - 11:48
la source
9

Plutôt que de stocker mes sites Web dans / var / www, je place des liens vers les sites situés dans mon dossier personnel. Je peux librement modifier ou ajouter des pages sur mes sites. Lorsque les modifications me conviennent, je fais alors un transfert FTP vers une société d’hébergement où mon nom de domaine est lié.

    
réponse donnée fragos 01.06.2011 - 09:06
la source
6

Si vous rendez / var / www accessible en écriture à son groupe et que vous vous ajoutez au groupe, vous n’aurez pas à utiliser sudo tout en étant relativement sécurisé. Essayez ceci:

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

Vous devriez alors pouvoir éditer /var/www/ fichiers sans tracas.

La première ligne vous ajoute au groupe www-data , la deuxième ligne efface tous les fichiers dont les droits de propriété sont altérés, et la troisième permet à tous les utilisateurs membres du groupe www-data de pouvoir lire et écrire tous les fichiers. fichiers dans /var/www .

    
réponse donnée Azendale 01.07.2011 - 02:41
la source
5

À ne pas faire

  • Ne définissez pas les autorisations de fichier sur 777 (en écriture dans le monde)

    .

    Il s'agit d'une faille de sécurité importante, en particulier si vous activez les scripts côté serveur tels que PHP. Les processus non privilégiés ne devraient pas être en mesure d'écrire dans des fichiers susceptibles d'affecter le site Web ou, en cas d'utilisation de scripts côté serveur, d'exécuter du code arbitraire.

  • Ne vous ajoutez pas en tant que membre du groupe www-data et ne lui accordez pas les autorisations d'écriture

    Le but de ce groupe est qu’il s’agisse d’un groupe non privilégié que le serveur traite en tant que. Ils devraient uniquement avoir un accès en lecture aux fichiers du site Web dans la mesure du possible, pour les mêmes raisons que ci-dessus.

  • Ne modifiez pas les autorisations des processus Apache

    Les processus enfants Apache s'exécutent en tant qu'utilisateur et groupe www-data par défaut, ce qui ne doit pas être modifié. C’est juste une façon de ne pas leur donner d’autorisation d’écriture sur le système de fichiers.

    Dans certaines circonstances, vous souhaitez que vos scripts côté serveur puissent écrire dans des fichiers. Dans ce cas, seulement ces fichiers doivent être rendus en écriture par www-data et vous devez veiller à ce qu'ils sécurité.

Dos

  • Définissez les fichiers comme appartenant à vous-même

    Si vous êtes le seul, ou le plus habituel, à modifier certains fichiers sur le site Web, il est alors tout à fait logique de prendre en charge ces fichiers. Définissez leur propriétaire sur <your username> .

    Vous n'avez pas besoin de modifier les autorisations du serveur pour cela, car le serveur continuera à avoir un accès en lecture seule, même lorsque les fichiers vous appartiennent.

  • Choisissez un endroit approprié pour stocker les fichiers (à l'aide de DocumentRoot )

    Si /var/www n'a pas de sens, vous pouvez les placer ailleurs. S'ils sont spécifiques à votre propre développement ou test, vous pouvez les placer dans votre répertoire personnel. Ou vous pouvez configurer certains répertoires dans /srv .

  • Si vous souhaitez accorder un accès en écriture au groupe , créez un nouveau groupe dans le but

    .

    Ne réutilisez pas un groupe de systèmes, car ceux-ci sont généralement conçus pour avoir l'accès qu'ils ont actuellement, sans plus, pour des raisons de sécurité.

réponse donnée thomasrutter 24.11.2016 - 00:43
la source
5

C'est aussi simple que cela. Vous n'avez pas besoin d'activer apache 'UserDir' (non recommandé) ni de vous mêler aux groupes 'www-data' (groupe apache en cas sur Fedora)

Créez simplement le répertoire de votre projet dans /var/www/html

cd /var/www/html
sudo mkdir my_project

Ensuite, envoyez simplement le répertoire du projet à votre utilisateur.

sudo chown your_username my_project

Vous pouvez maintenant commencer à travailler sur votre dossier de projet en tant qu'utilisateur standard avec n'importe quel éditeur, IDE de votre choix. Plus de sudos :)

    
réponse donnée reversiblean 06.08.2016 - 09:49
la source
1

chmod dans / var sur www pour autoriser l'accès du propriétaire, et chown pour s'assurer que vous le possédez. Probablement une idée stupide, mais cela fonctionnerait certainement.

    
réponse donnée Daniel 01.06.2011 - 05:59
la source
1

Vous pouvez démarrer une session www dans un terminal en

.
sudo su www-data

Combiné avec une invite * de couleur différente, pour rendre plus évident le fait qu’il s’agit du shell d’un utilisateur différent, et une politique qui consiste à toujours mettre le xterm (et l’éditeur et autres) correspondants - par exemple - le bureau virtuel 4 , afin que vous vous y habituiez, pour éviter toute confusion.

*) Pour une invite de couleur différente avec un caractère différent, créez un fichier / etc / prompt comme ceci:

# 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

et sourcez-le à partir de /etc/bash.bashrc par exemple.

En tant qu'outil supplémentaire permettant de distinguer les utilisateurs, vous pouvez toujours éditer vos fichiers avec un alias "edit" ou un lien symbolique, qui pointe en fonction de votre identité (taylor / www-data) sur gedit ou mousepad, vim ou pico. Vous pouvez également utiliser différents profils d’éditeur. Par exemple, dans gedit, vous pouvez définir vos préférences en texte noir sur fond blanc ou en blanc sur fond noir.

Je ne dispose que d'une telle stratégie pour travailler en tant qu'utilisateur root. Par conséquent, je ne sais pas si cela conviendra à l'utilisation de www-data. Combiné avec ssh-sessions à différents hôtes, qui ont leurs propres invites, cela ne m'a pas empêché de me tromper parfois, mais si cela se produit, je me rends vite compte de ce qui ne va pas et cela arrive rarement.

note: le script d'invite est en partie une copie de la page de manuel de bash.

    
réponse donnée user unknown 01.06.2011 - 17:49
la source
-1

Sur cette page de mon site , je couvre les commandes permettant de modifier l'autorisation, dans /var/www , entre apache et pi utilisateur mais son essentiel

sudo chown -R pi /var/www

puis un redémarrage apache

sudo service apache2 restart
    
réponse donnée Nathan Dickson 24.11.2016 - 00:27
la source

Lire d'autres questions sur les étiquettes