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

Je veux cesser d'utiliser sudochaque fois que je travaille /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.

La plupart des réponses ne sont pas écrites dans un souci de sécurité. C'est bien de sentir que courir à sudochaque fois n'est pas très sage. Si vous faites une faute de frappe (par exemple un seul espace blanc au mauvais endroit: sudo rm -rf / var/www/dir ne pas exécuter! ), Vous risquez de détruire votre système.

Remarque: à partir de Apache 2.4.7 / Ubuntu 14.04, /var/wwwa été déplacé vers /var/www/htmlAjuster les commandes dans cette réponse en conséquence.

Voir:

• Où placer mon site Web local à partir de la version 2.4.7 d’apache2?

• Pourquoi le répertoire www apache2 a-t-il été déplacé vers / var / www / html?

• Changer la racine du document par défaut pour le serveur HTTP

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 l' www-datautilisateur
• chgrp -R www-data $HOME(cob) - cela permet www-datade 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 /var/www, le serveur Web exécuté www-datane 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, c'est bien le cas.

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

www-data

Certains serveurs Web fonctionnent en tant que www-data. Le contenu Web ne doit pas appartenir à cet utilisateur, sinon un serveur Web compromis pourrait réécrire un site Web. Les données écrites par les serveurs Web seront la propriété de www-data.

Si possible, n'accordez pas d' autorisations d'écriture au www-datagroupe. www-datadoit seulement pouvoir lire les fichiers pour que le serveur Web puisse le servir. Le seul cas où www-datades autorisations en écriture sont nécessaires concerne les répertoires stockant les téléchargements et d'autres emplacements à écrire.

Solution 1

Ajoutez-vous au www-datagroupe et définissez le bit setgid sur le /var/wwwrépertoire 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 640ou 2750et manuellement chmod g+w file-or-dirqui doit être accessible en écriture 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/fooet que vous souhaitez l'avoir situé à /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 le groupe www-data, mais définissez le bit d'exécution uniquement (pas de lecture / écriture). Faites de même pour le ~/projectsdossier car il peut contenir d’autres projets que www. (Vous n'avez pas besoin sudosi vous avez déjà ajouté votre utilisateur au www-datagroupe.)

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

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

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 chaque fichier nouvellement créé ~/projects/foosoit accessible au groupe.

A partir de maintenant, vous pouvez accéder à votre site à http://localhost/fooet modifier vos fichiers de projet en ~/projects/foo.

Voir également

• Problème de permissions: comment Apache peut-il accéder aux fichiers de mon répertoire de base?
• Raisons pour lesquelles / var / www ne devrait pas avoir chmod 777

Plutôt que de stocker mes sites Web dans / var / www, j'y 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é.

Si vous faites en sorte que / var / www soit inscriptible par son groupe et que vous vous ajoutiez au groupe, vous n’aurez pas à utiliser sudo tout en restant relativement sécurisé. Essaye ça:

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 des /var/www/fichiers sans tracas.

La première ligne vous ajoute au www-datagroupe, la seconde efface tous les fichiers dont les droits de propriété sont perturbés et la troisième permet à tous les utilisateurs membres du www-datagroupe de lire et d’écrire tous les fichiers /var/www.

À ne pas faire

• Ne définissez pas les autorisations de fichiers sur 777 (accessible en écriture)

  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 donnez-lui des autorisations d'écriture.

  Le but de ce groupe est qu’il s’agisse d’un groupe sans privilèges dans lequel les processus du serveur sont exécutés. 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 changez pas les permissions des processus Apache

  Les processus enfants Apache s'exécutent en tant www-dataqu'utilisateur et groupe par défaut, ce qui ne devrait pas être modifié. C'est juste une façon de leur donner aucune permission 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, seuls ces fichiers doivent être accessibles en écriture www-dataet un soin particulier doit être pris pour assurer la 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 à 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 (en utilisant DocumentRoot )

  Si cela /var/wwwn’a aucun 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 donner un accès en écriture au groupe , créez un nouveau groupe à cette fin.

  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é.

C'est aussi simple que ça. 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 votre répertoire de projet à l'intérieur /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 régulier avec n'importe quel éditeur, IDE de votre choix. Pas plus sudos :)

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.

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

sudo su www-data

Combiné à une invite * de couleur différente, il est plus évident que c’est le shell d’un autre utilisateur et une règle qui consiste à toujours mettre le xterm (et son éditeur) correspondant - par exemple - le bureau virtuel 4, de sorte que vous vous y habituez, 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 le source de /etc/bash.bashrcpar exemple.

En tant qu'outil supplémentaire pour vous aider à distinguer, vous pouvez toujours éditer vos fichiers avec un alias "edit" ou un lien symbolique, ce 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.

J'ai une telle politique pour travailler en tant que root, donc je ne sais pas à quel point cela conviendra pour travailler avec 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.

Remarque: le script-invite est en partie une copie de la page de manuel de bash.