web-dev-qa-db-fra.com

Autorisation SFTP refusée sur les fichiers appartenant à www-data

J'ai un serveur assez standard configuré avec Apache et PHP. Une application que je suis en train de créer crée des fichiers qui appartiennent à l'utilisateur Apache www-data. Les fichiers que je télécharge via SFTP sont la propriété de mon propre utilisateur charlesr. Tous les fichiers font partie du groupe www-data. Mon problème est que je ne peux ni modifier ni écraser les fichiers via SFTP appartenant à www-data, même si charlesr fait partie du groupe www-data. Je peux modifier les fichiers sans problème via une session SSH.

Donc je ne sais pas quoi faire. Comment puis-je donner à ma session SFTP le droit de modifier les fichiers possédés par www-data?

Pour rappel, voici les notes que j'ai écrites lors de la configuration du serveur:

Now set up permissions on `/var/www` where your files are served from by
default:

$ Sudo adduser $USER www-data
$ Sudo chgrp -R www-data /var/www
$ Sudo chmod -R g+rw /var/www
$ Sudo chmod -R g+s /var/www

Now log out and log in again to make the changes take hold.

The previous set of commands does the following:

1. adds the current user ($USER) to the `www-data` group;
2. changes `/var/www` to belong to the `www-data` group;
3. adds read/write permissions to the group that `/var/www` belongs to;
4. sets the SGID bit on `/var/www`; this final point bears some explaining.

Ensuite, je me explique le réglage du bit SGID (c’est-à-dire que tous les fichiers créés dans /var/www font automatiquement partie du groupe www-data).

UPDATE

Il semble que le problème soit causé par l'application elle-même ou, plus précisément, par le cadre d'application ( Kohana ) qui définit certains fichiers qu'il écrit dans 0644 (rw-r - r--); c'est-à-dire pas en écriture de groupe. Ceci, couplé au fait que les fichiers sont également la propriété de www-data, signifiait que je ne pouvais pas éditer les fichiers via SFTP lorsque connecté en tant que charlesr. Je ne sais pas pourquoi je pourrais éditer les fichiers via SSH. Je suppose que j'ai dû utiliser Sudo.

Voici la stratégie de permissions que j’utilise maintenant grâce à aide infatigable de Marty Fried , qui a souligné les failles de ma stratégie précédente et qui m’a également aidé à naviguer dans le monde des permissions Linux jusqu’à ce que j’y arrive enfin. Merci Marty!

Vue d'ensemble

  • Les fichiers et les répertoires de /var/www devraient appartenir à root:webmasters
  • Tous les développeurs doivent être membres du groupe webmasters
  • Tous les répertoires de /var/www doivent être définis sur: 2775 ou u=rwx,g=rwxs,o=rx (rwxrwx-r-x)
  • Tous les fichiers dans /var/www doivent être définis sur: 0664 ou ug=rw,o=r (rw-rw-r--)

Les éléments suivants doivent appartenir à www-data:webmasters (c’est-à-dire que ce sont les répertoires dans lesquels Apache doit pouvoir écrire):

  • application/cache
  • application/journaux
  • télécharger
  • client_helpers/upload

COMMENT

Pour configurer les autorisations sur /var/www à partir duquel vos fichiers sont servis par défaut:

  1. Sudo addgroup webmasters
  2. Sudo adduser $USER webmasters
  3. Sudo chown -R root:webmasters /var/www
  4. Sudo find /var/www -type f -exec chmod 664 {} \;
  5. Sudo find /var/www -type d -exec chmod 775 {} \;
  6. Sudo find /var/www -type d -exec chmod g+s {} \;
  7. Sudo chown -R www-data:webmasters application/cache/ [etc ...]

Maintenant, déconnectez-vous et reconnectez-vous pour que les modifications soient prises en compte.

Le jeu de commandes précédent effectue les opérations suivantes:

  1. Créez un nouveau groupe appelé webmasters; tous les utilisateurs ayant besoin d'un accès en écriture aux fichiers de l'application seront ajoutés à ce groupe.
  2. ajoute l'utilisateur actuel ($USER) au groupe webmasters.
  3. change le propriétaire de /var/www en root et le groupe en webmasters group.
  4. ajoute autorisations 664 (-rw-rw-r--) à tous les fichiers de /var/www.
  5. ajoute autorisations 775 (drwxrwxr-x) à tous les répertoires de /var/www.
  6. définit le bit SGID sur /var/www et tous ses répertoires; ce dernier point mérite quelques explications. Notez également que vous pouvez également mettre un 2 à l'avant de votre octal chmod (par exemple 2644) pour faire la même chose.
  7. définit le propriétaire sur www-data (utilisateur d'Apache) et le groupe du répertoire fourni sur webmaster. Cela garantit que le répertoire est accessible en écriture par Apache et tous les utilisateurs du groupe webmasters. Faites de même pour tous les autres répertoires devant être accessibles en écriture.
permissionsapache2sftp
23
Charles Roper

Ubuntu.com a de très bons guides de serveur, tels que Guide Apache . Où avez-vous obtenu vos procédures que vous avez si soigneusement écrites? Je n’ai jamais eu autant de problèmes avec les serveurs que j’ai configurés, bien que je sois ouvert à la possibilité de ne pas le faire correctement. En outre, je n’ai pas réellement installé de serveurs pour. tout ce qui est très public, ou très grand, donc il pourrait y avoir des failles de sécurité que je ne connais pas.

Cependant, je n'ai jamais eu besoin d'être membre du groupe www-data et aucun fichier source dans www n'est la propriété de www-data. D'après ce que j'ai compris, Apache l'utilise uniquement pour ses propres fichiers. Il ne dispose d'aucun droit en écriture sur les autres fichiers car, en théorie, aucun fichier important n'autorisera www-data à disposer du droit en écriture. J'imagine que les fichiers appartenant à www-data donneraient une autorisation en lecture seule à tout le monde, et que personne ne devrait avoir l'autorisation d'écrire sur ses fichiers. Bien sûr, je peux me tromper totalement, et si tel est le cas, j'espère que quelqu'un me le dira et me dirigera vers une documentation expliquant différemment (pas sur un forum où un internaute aléatoire comme moi a produit des instructions qui ont fonctionné pour lui).

Peut-être me manque quelque chose, mais votre problème devrait être assez simple. L'utilisateur connecté à l'aide de sftp doit être membre du groupe www-data et les fichiers que vous tentez de modifier doivent disposer d'autorisations en écriture pour le groupe www-data. Cela ne me semble pas logique de pouvoir modifier les fichiers avec ssh, mais pas avec sftp; Êtes-vous sûr de vous connecter au même compte pour les deux? Dans sftp, vous pouvez entrer des commandes telles que !groups pour répertorier vos groupes ou !whoami pour vérifier le nom de connexion que vous utilisez. Les résultats doivent correspondre à ce que vous voyez avec ssh (avec les mêmes commandes moins le point d’exclamation).

Vous devriez aussi pouvoir utiliser chmod, chown, chgrp de sftp si vous en avez la permission.

En passant, je pense que votre liste a au moins une commande assez mauvaise:

Sudo chmod -R g+rw /var/www

Cela donne au monde les droits d’écriture sur tous les fichiers et tous les dossiers de/var/www. Cela semble être une mauvaise idée. Normalement, seul l'utilisateur root est autorisé à écrire sur ces répertoires, à moins que des répertoires spécifiques ne nécessitent davantage d'autorisations, généralement des répertoires uniques.

Remarque: il s'agissait d'une erreur de ma part. Merci à DonalLafferty de l'avoir signalé, il spécifie "g" et non "a", de sorte qu'il ne modifie que les autorisations du groupe. Mes vieux yeux fatigués (ou une mauvaise police) ont dû le lire comme "a".

Éditions de clarification

Normalement, les fichiers créés par Apache sont en lecture seule pour le groupe www-data et tous les autres utilisateurs, comme pour les fichiers appartenant à la racine dans/var/www. Il ne devrait donc y avoir aucune raison de faire de quiconque un membre de www-data. Le problème est de donner à tous un accès en écriture, ce qui est un cas différent. Cela devrait être fait en rendant des répertoires spécifiques disponibles sur votre site, et cela simplement en utilisant chmod, soit avec Sudo, puisqu'il appartient probablement à root, soit en rendant le propriétaire vous-même et non en utilisant Sudo.

Si plusieurs développeurs ont besoin d'accéder à l'ensemble du site, vous devez créer un groupe d'utilisateurs + tel que "Webmasters", en faire le propriétaire du site, accorder des autorisations en écriture à ce groupe et rendre tous les membres devs membres. de ce groupe. Ainsi, la liste des répertoires de sites ressemblerait à quelque chose comme:

drwxrwxr-x  ##  webmasters     webmasters   #### ####-##-## ##:##  mysite.com

Plus de modifications

Depuis, j'ai réalisé qu'il n'était pas vraiment nécessaire de créer un utilisateur "webmasters", mais simplement un groupe. Ensuite, les fichiers peuvent appartenir à root: webmasters, c’est-à-dire que root est le propriétaire, mais que les webmasters sont le groupe.

En réponse aux questions ci-dessous, les fichiers écrits par Apache seront la propriété de www-data et du groupe www-data. Ces fichiers ne sont normalement pas des éléments auxquels vous écrivez. Par conséquent, les non-membres de www-data peuvent avoir un accès en lecture seule. Je pense que cela dépend des autorisations du répertoire. Si vous avez besoin de plus qu'un accès en écriture occasionnel, il pourrait être utile de vous ajouter au groupe. Habituellement, vous créez des répertoires spécifiques en écriture pour le contenu enregistré par Apache. Sachez également que la plupart des hébergements Web partagés exécutant Apache sans accès au shell ne seraient même pas en mesure de configurer des groupes.

Mais Apache peut lire des fichiers appartenant même à root. Presque tous les fichiers ont un accès lisible par tout le monde, mais pas en écriture. Donc, à moins que vous ne vouliez changer cela, Apache n'a pas besoin d'être dans le groupe des webmasters.

Ceci est toute la configuration de base de Linux, pas vraiment Apache. Apache ne se préoccupe que de l'accès depuis le serveur Web, et cela est défini par les fichiers de configuration. Pour cette raison, le lien vers la documentation Ubuntu que j'ai inclus dans mon message devrait être considéré comme une meilleure source qu'un wiki public.

À propos, le livre de recettes O'Reilly Apache indique que "les répertoires de documents, tels que htdocs, cgi-bin et icons, devront disposer d’autorisations définies de la manière la plus logique pour le modèle de développement de votre site Web, mais en aucun cas l’un de ces répertoires ou fichiers ne devrait être accessible en écriture à l’utilisateur du serveur Web. "

Enfin, l'utilisation des ACL est un bon moyen de définir des autorisations de fichiers si vous avez besoin de plus de contrôle. C'est peut-être même un bon moyen de les régler tout le temps et c'est une chose sur laquelle je devrais enquêter.

10
Marty Fried

J'ai remarqué que vous n'aviez pas utilisé chown.

Pour définir correctement la propriété des fichiers/dossiers, vous pouvez définir l’ensemble du répertoire de la manière suivante: chown -R www-data:www-data

Ceci définit la propriété sur le groupe www-data et l'utilisateur www-data

En outre, vous pouvez le faire comme solution de contournement temporaire:

chmod 777 /var/data/<filename> ou chmod 777 /var/data/<foldername>

éditez le ou les fichiers selon vos besoins, puis

chmod 644 /var/data/<filename> ou chmod 755 /var/data/<foldername>

Veillez à utiliser le commutateur "-R", car il modifie également les autorisations de tous les sous-fichiers et dossiers.

664 sont les autorisations de fichiers standard Apache et 755 les autorisations de dossiers standard.

J'espère que cela t'aides :)

Étoile

6
StarBlessed