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


Je veux arrêter d'avoir à 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.


162
2018-06-01 03:43


origine


Utilisez-vous Apache? - Rinzwind
Après avoir lu ici, cela peut aussi aider dans la partie permission: askubuntu.com/questions/20105/… - Luis Alvarado♦
Une autre façon d’obtenir la sécurité est de continuer à utiliser sudo -u www-data mais limitez-vous dans le sudoers fichier pour seulement pouvoir sudo www-data (et pas sudo root). Voir serverfault.com/questions/295429/… - Simon Woodside


Réponses:


La plupart des réponses ne sont pas écrites dans un souci de sécurité. C'est bien d'avoir le sentiment que courir sudo chaque fois n'est pas très sage. Si vous faites une faute de frappe (par exemple (ne pas exécuter) sudo rm -rf / var/www/dir), vous pourriez détruire votre système.

Remarque: À partir d'Apache 2.4.7 / Ubuntu 14.04, /var/www a été déplacé à /var/www/html Ajustez les commandes dans 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 et permettant ainsi à l’intrus d’exécuter du code sous le www-data utilisateur
  • chgrp -R www-data $HOME (cob) - cela permet www-data pour lire ou écrire des fichiers dans le répertoire personnel. Cela ne tient pas compte de la règle des privilèges minimum
  • chown -R $USER:$USER /var/www (kv1dr) - à moins que le monde ait lu les autorisations sur /var/www, le serveur web fonctionnant sous www-data ne sera pas en mesure de lire (servir) les fichiers. Si le fichier est un document HTML ordinaire accessible au public, cela pourrait ne pas être un problème si le monde pouvait 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é www-data écrire des privilèges. cependant, /usr/share/doc/base-passwd/users-and-groups.txt.gz États:

www-data

Certains serveurs Web fonctionnent en tant que www-data. Le contenu Web ne devrait pas être la propriété de ce     Un utilisateur ou un serveur Web compromis pourrait réécrire un site Web. Les données     écrit par les serveurs Web sera la propriété de www-data.

Dans la mesure du possible, faire ne pas accorder des autorisations d'écriture sur le www-data groupe. www-data n'a besoin que de pouvoir lis les fichiers afin que le serveur Web puisse le servir. Le seul cas où www-data nécessite des autorisations d'écriture pour les répertoires stockant des téléchargements et d'autres emplacements qui doivent être écrits.

Solution 1

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

sudo gpasswd -a "$USER" www-data

Corriger les fichiers précédemment créés (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: utiliser 640 ou 2750 et manuellement chmod g+w file-or-dir qui doit être accessible en écriture par le serveur Web)

Solution 2

Créez un lien symbolique pour chaque projet dans votre répertoire personnel. Disons que votre projet est situé à ~/projects/foo et vous voulez l'avoir situé à /var/www/foo, courir:

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

Si votre répertoire d’accueil n’a pas de bit d’exécution (descend) défini pour other (pour des raisons de sécurité), changez le groupe en www-data, mais définir le bit d'exécution uniquement (pas de lecture / écriture). Faites la même chose pour le ~/projectsdossier comme il peut contenir d'autres projets que www. (Vous n'avez pas besoin sudo si vous avez déjà ajouté votre utilisateur au www-data groupe.)

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

Définissez le groupe sur www-data sur ~/projects/foo et permettre au serveur Web de lire et d’écrire des fichiers et des fichiers + des répertoires et de descendre dans des 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 modifiez manuellement les fichiers et répertoires qui doivent être accessibles en écriture pour l'utilisateur du serveur Web. Le bit setgid ne doit être ajouté que si vous voulez que chaque nouveau fichier créé ~/projects/foo être accessible par le groupe.

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

Voir également


229
2018-06-01 09:48



Que pensez-vous d'une session de www dans un terminal par sudo su www-data? Combiné avec une invite de couleur différente, pour rendre plus évident le fait que ce soit le shell d'un utilisateur différent, et une politique pour toujours mettre le xterm correspondant - par exemple - le bureau virtuel 4, pour que vous vous y habituiez, éviter la confusion? - user unknown
@user unknown: si vous faites tout dans le terminal, vous avez une séparation claire entre les comptes utilisateurs. Mais cela ne fonctionnera pas si vous utilisez un programme graphique comme gedit. Je n'ai jamais cherché à savoir si l'exécution d'un programme graphique sous un autre utilisateur dans la session en cours est sûre ou non, ce serait une question intéressante. - Lekensteyn
@imaginaryRobots: si je devais poster différentes solutions pour chaque question, Askubuntu serait plein de réponses de trois lignes. Je le garderai tel quel, à moins de pouvoir me convaincre de le diviser. - Lekensteyn
@berbt setfacl -d u::rwX,g::rX /var/www a l'effet amusant que le mode par défaut devient 0750 (ou 0640) même si le masque est nul. Cela peut être une bonne idée si vous voulez éviter les fichiers accessibles en écriture, mais si /var/www est déjà inaccessible par le monde il n'est pas nécessaire. - Lekensteyn
Y a-t-il un problème avec l'inversion du processus dans la solution 1? Par cela je veux dire, /var/www/app01 a la propriété app01:app01, puis le www-data  utilisateur est ajouté à la app01  groupe? Ou est-ce que ça cassera quelque chose? - Jack_Hu


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 à mes sites. Lorsque je suis heureux avec les changements, je transfère ensuite un FTP vers un hébergeur où mon nom de domaine est lié.


7
2018-06-01 07:06



C'est une idée judicieuse. - thomasrutter


Si vous autorisez / var / www à écrire par son groupe et à vous ajouter au groupe, vous ne devrez pas utiliser sudo tout en étant assez 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 modifier /var/www/ fichiers sans tracas.

La première ligne vous ajoute à la www-data groupe, la deuxième ligne efface tous les fichiers avec propriété corrompue, et le troisième fait en sorte que tous les utilisateurs qui sont membres de la www-data groupe peut lire et écrire tous les fichiers dans /var/www.


6
2017-07-01 00:41



C'est une très mauvaise idée pour la sécurité et ce conseil ne doit pas être suivi, pour des raisons expliquées dans d'autres réponses. www-data est censé être un sans privilèges groupe, sans accès en écriture. - thomasrutter


A ne pas faire

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

    Ceci est une faille de sécurité importante, surtout si vous activez des scripts côté serveur tels que PHP. Les processus non privilégiés ne devraient pas pouvoir écrire dans les fichiers susceptibles d'affecter le site Web ou, dans le cas de scripts utilisés côté serveur, d'exécuter du code arbitraire.

  • Ne vous ajoutez pas en tant que membre du www-data grouper et lui donner des permissions d'écriture

    L’objectif de ce groupe est que c’est un sans privilèges groupe que le processus serveur courir comme. Ils ne devraient avoir accès en lecture aux fichiers du site Web que 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 que www-data utilisateur et groupe par défaut, et cela ne doit pas être modifié. Ceci est juste un moyen 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, auquel cas seulement ces fichiers doivent être accessibles en écriture par www-data et des précautions doivent être prises pour assurer la sécurité.

Dos

  • Définissez les fichiers à posséder par vous-même

    Si vous êtes le seul, ou le seul, à modifier certains fichiers sur le site Web, il est tout à fait logique de s’approprier ces fichiers. Mettre leur propriétaire à <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 si les fichiers vous appartiennent.

  • Choisissez un endroit judicieux pour héberger les fichiers (en utilisant Document racine)

    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 voulez donner groupe accès en écriture, créer 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, et pas plus, pour des raisons de sécurité.


5
2017-11-23 23:43





C'est aussi simple que ça Vous n'avez pas besoin d'activer apache 'UserDir' (non recommandé) ni de gâcher les groupes 'www-data' (groupe Apache dans Fedora)

Créez simplement votre répertoire de projet à l'intérieur /var/www/html

cd /var/www/html
sudo mkdir my_project

Ensuite, placez simplement le répertoire du projet sur 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 :)


5
2017-08-06 07:49



+1 C'est ce que je fais: changer de propriétaire, pas de /var/www lui-même, mais des sous-répertoires. - fkraiem


chmod dans / var sur www pour permettre l'accès propriétaire, et chown pour vous assurer que vous en êtes propriétaire. Probablement une idée stupide, mais ça marcherait certainement.


1
2018-06-01 03:59



Pas une idée stupide, c'est une idée judicieuse sur le plan de la sécurité. Remarque: Vous n'avez pas besoin (et ne devez pas) modifier les autorisations de /var, juste /var/www et / ou son contenu. - thomasrutter


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 que ce soit le shell d'un utilisateur différent, et une stratégie pour toujours placer le xterm (et l'éditeur et autres) correspondants - par exemple - le bureau virtuel 4, 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.bashrc par exemple.

Comme outil supplémentaire pour faciliter la distinction, vous pouvez toujours éditer vos fichiers avec un alias "edit" ou un lien symbolique, qui pointe, selon votre identité (taylor / www-data) vers gedit ou mousepad, vim ou pico. Ou vous pouvez utiliser différents profils d’éditeur, du moins dans gedit, vous pouvez par exemple définir vos préférences sur du texte noir sur fond blanc ou du texte blanc sur fond noir.

Je n'ai qu'une telle politique pour travailler en tant que root, donc je ne suis pas sûr de savoir comment cela va fonctionner pour travailler avec www-data. Combiné à des sessions ssh pour différents hôtes, qui ont leurs propres invites, cela ne m'a pas empêché d'être parfois faux, 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.


1
2018-06-01 15:49



Cela fonctionnera et n'aura pas (si utilisé avec précaution) un impact négatif sur la sécurité, mais peut ne pas être la solution la plus simple. C'est une solution valable pour certaines personnes cependant. - thomasrutter


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

sudo chown -R pi /var/www

puis un apache redémarrer

sudo service apache2 restart

-1
2017-11-23 23:27



Le lien fonctionne maintenant - Gadgetroid