Impossibilité de modifier passwd utilisateur

Bonjour,

Sur un VPS2, je n'arrive pas à modifier le mot de passe de l'utilisateur www-data:

root@vpsxxxxxx:/var/www# passwd www-data
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
root@vpsxxxxxx:/var/www# su www-data
This account is currently not available.
root@vpsxxxxxx:/var/www# vi /etc/passwd <– rien d'anormal
root@vpsxxxxxx:/var/www# vi /etc/shadow <– il a bien modifié la ligne de www-data


Contexte : j'ai lancé ce VPS en demandant une install de Drupal (7 que j'ai réinstallée en 8), et je voudrais utiliser Composer pour travailler sur cette instance de Drupal. Or il ne faut pas lancer Composer en root, il faut le lancer sous un utilisateur à droits normaux. Comme il va modifier et créer des fichiers sous /var/www, j'ai pensé le lancer en user=www-data, c'est le owner des fichiers qui sont sous /var/www

Merci de votre aide

Bonjour,

De mémoire déjà faut pas trop toucher au password de www-data, en plus il a pas de shell normalement (j'ai vérifié vite fait).

Pourquoi ne pas créer un utilisateur "normale" et installer drupal dans son /home ?

Cordialement, janus57


Pourquoi ne pas créer un utilisateur "normale" et installer drupal dans son /home ?


je pensais qu'il fallait que www-data soit propriétaire des fichiers, et qu'ils soient sous www, c'est en tout cas comme ça qu'il m'a fait l'install de Drupal 7 au départ. www-data est également propriétaire du répertoire où se trouve la base de données.

Mais bon, si tu me dis qu'on peut lui donner un autre propriétaire, je vais essayer. Quant à l'emplacement, il faut absolument que ce soit sous /var/www sinon ce ne sera pas vu du web. Mais l'emplacement ne me pose pas de problème, ce qui me pose problème c'est l'owner. Je vais essayer de le modifier.

Bonjour,


www-data est également propriétaire du répertoire où se trouve la base de données.

heu ça c'est pas possible car généralement c'est mysql (ou autre selon le type de BDD).

il faut absolument que ce soit sous /var/www sinon ce ne sera pas vu du web.

absolument faux, j'ai des sites qui tournent depuis 2ans dans leur /home (1 site == 1home == 1 utilisateur) pour les isoler, qu'il est chacun leur accès SFTP et SSH.
Après c'est seulement une question de configuration du serveur web (apache/nginx ou n'importe).

Et dans /var/www/ c'est bien www-data qui doit être l'owner.

Cordialement, janus57


j'ai des sites qui tournent depuis 2ans dans leur /home (1 site == 1home == 1 utilisateur) pour les isoler, qu'il est chacun leur accès SFTP et SSH.
Après c'est seulement une question de configuration du serveur web (apache/nginx ou n'importe).


Comment fais-tu pour signaler que l'url doit atterrir dans /home plutôt que dans /var/www? Si on a un nom de domaine je vois comment faire, mais si on n'a pas de nom de domaine? (car dans le cas présent je n'en ai pas, c'est juste pour un essai, je tape directement le nom du vps dans l'adresse du navigateur).

Bonjour,

simple suffit de le dire au serveur via sa configuration.

Typiquement sous apache c'est : DocumentRoot
> DocumentRoot /home/utilisateur/public_html/
>
> Require all granted
>

Note : toujours regarder la doc de son logiciel on trouve plein de choses utile (comme le fait de ne pas activer les .htaccess ou ce genre d'améliorations).

Exemple à la va vite :
http://cm63.janus57-testing.tk/

> janus57@vps:~# ls -alh /home/cm63/
> total 28K
> drwxr-xr-x 3 cm63 cm63 4,0K mai 17 21:44 .
> drwxr-xr-x 11 root root 4,0K mai 17 21:42 ..
> -rw------- 1 cm63 cm63 140 mai 17 21:44 .bash_history
> -rw-r–r-- 1 cm63 cm63 220 mai 17 21:42 .bash_logout
> -rw-r–r-- 1 cm63 cm63 3,5K mai 17 21:42 .bashrc
> -rw-r–r-- 1 cm63 cm63 675 mai 17 21:42 .profile
> drwxr-xr-x 2 cm63 cm63 4,0K mai 17 21:44 public_html
> janus57@vps:~# ls -alh /home/cm63/public_html/
> total 12K
> drwxr-xr-x 2 cm63 cm63 4,0K mai 17 21:44 .
> drwxr-xr-x 3 cm63 cm63 4,0K mai 17 21:44 ..
> -rw-r–r-- 1 cm63 cm63 42 mai 17 21:47 index.html
> janus57@vps:~# cat /home/cm63/public_html/index.html
> Bonjour CM63, l'utilisateur du forum OVH.

Cordialement, janus57

Ok, mais bon encore une fois mon problème n'est pas l'emplacement mais les droits qu'il y a .
En fait /var/www appartient à root, c'est dessous, le répertoire drupal qui appartient à www-data. J'ai donné un shell à www-data grâce à la commande moduser, j'ai pu me connecter sous www-data, je vais voir si je peux utiliser Composer comme cela.

Bonjour,

le fait d'avoir donner un shell a www-data pose un problème de sécurité car il n'est pas censé avoir de shell.
Perso je persiste à dire que c'est une très mauvaise idée surtout que j'ai prouvé juste au dessus qu'un utilisateur "normale" peu avoir son site (dans son /home) et a accès au commande de base (donc y compris composer si vous l'installer), il peu même faire du mysqldump, du mysql, du php en cli etc.

Cordialement, janus57

Oui mais il faudra que je fasse pointer le site sur le home de cet utilisateur normal et donc on se récupère la faille de sécurité.

Il faudra faire DocumentRoot /home/utilisateur/public_html/ et donc on a le même problème de sécurité.

Tu fais comment pour utiliser Composer sans donner un shell au propriétaire des fichiers du CMS?


Oui mais il faudra que je fasse pointer le site sur le home de cet utilisateur normal et donc on se récupère la faille de sécurité.

pourquoi ??

Il faudra faire DocumentRoot /home/utilisateur/public_html/ et donc on a le même problème de sécurité.

bah non il remontera pas plus haut que son /home si c'est bien config et on peu le chroot ou utiliser d'autre techniques/logiciels.

Tu fais comment pour utiliser Composer sans donner un shell au propriétaire des fichiers du CMS?

mes utilisateurs pour les site web ont un shell tout simplement, mais en aucun cas j'utilise www-data qui permet de faire tourner le serveur apache, encore moins en lui donnant un shell qui peu potentiellement lui donner plus de pouvoir.

https://serverfault.com/questions/559290/does-www-data-user-need-a-real-shell/559315#559315 & https://askubuntu.com/questions/486346/this-account-is-currently-not-available-error-when-trying-to-ssh/486661#486661

Cordialement, janus57

Ok, merci de ton aide. En fait il suffirait de lancer Composer sous un utilisateur qui aurait le droit d'écrire sous un répertoire dont www-data est propriétaire, mais qui ne soit pas www-data lui-même. Je suppose que c'est ce que tu as fait.
Mais est-ce qu'il ne faudrait pas plutôt travailler dans 2 environnements différents (ok je réinvente la roue, mais je comprends mieux maintenant l'intérêt de ces deux environnements):

Environnement dev:
* pas accessible par le web, pas pointé par le domaine,
* on a un shell, on utilise Composer en ligne de commande
* on y développe

Environnement prod:
* accessible par le web, pointé par le domaine,
* on n'a pas de shell, on n'utilise pas Composer, car:
* on n'y développe pas

Je vais cliquer dans "résolu" car c'est un autre sujet.

Bonjour,


Je suppose que c'est ce que tu as fait.


Non du tout situation regarde mon message de hier le seul propriétaire et groupe est l'utilisateur cm63.

Pour avoir un "vrai" environnement de dev, celui-ci devrais être en local (avec un PC qui permet de virtualisation un petit debian cela suffit largement) ou dans une autre machine virtuelle (ou vps) pour éviter au maximum les problèmes/risques.

Cordialement, janus57


Pour avoir un "vrai" environnement de dev, celui-ci devrais être en local (avec un PC qui permet de virtualisation un petit debian cela suffit largement) ou dans une autre machine virtuelle (ou vps) pour éviter au maximum les problèmes/risques.


Oui, j'opte pour le vps car je n'ai pas envie d'installer les serveurs sur mon PC.

Bonjour,

perso les test/dev bien souvent sont fait en local en machine virtuelle pour 3 raisons :
1 - elle ont pas un accès directe à internet comme un VPS
2 - plus simple de sauvegarder une VM complète en local
3 - l'environnement local et distant seront strictement les même et il suffit de rsync les fichier de "dev" vers la prod une fois que tout est stable/propre (cela inclus les fichiers des sites ou de la config d'un service comme apache/php, ce qui permet d'avoir une save local des paramètres en plus).

4 (bonus) - c'est gratuit d’utiliser mon PC (mise à part payer électricité), cela prend peu de place (8/10Go sa entre), cela prend peu de RAM (je lui donne 2Go pas plus) et je peu dupliquer/snapshot autant de fois que je veux (sans payer ou avoir des contraintes lié à un hébergeur).

Cordialement, janus57