[Custom Webapp] Permissions pour un dossier

Mon serveur YunoHost

Matériel: VPS OVH Starter
Version de YunoHost: 4.3.5 (dernière)
J’ai accès à mon serveur : en SSH
Êtes-vous dans un contexte particulier ou avez-vous effectué des modifications particulières sur votre instance ? : non

Description du problème

Salut tout le monde,

Pour héberger un petit script qui me permet à moi et à plusieurs personnes d’une rédaction de compresser et redimensionner des images à une taille idéale pour site web, j’ai installé Custom Webapp.

Dans un premier temps j’ai eu un souci : aucun accès possible en SFTP avec Filezilla, visiblement y’a un problème de permissions. J’ai donc décidé de passer en SSH et de créer moi-même les dossiers et fichiers (en c/c, c’est barbare mais quand on patine depuis des heures…).

Mais j’ai encore un problème : Le script a besoin d’un dossier “uploads” à sa racine pour les images à redimensionner, sauf qu’il n’y accède pas. Le temps de tester je lui ai fait un chmod 777 et ça a fonctionné (je ne l’ai évidemment pas laissé ainsi). On est donc sur un souci de permissions.

Maintenant je sèche, je suis sûr que c’est un problème tout bête mais je ne trouve rien, alors si jamais vous avez une piste…

Merci d’avance,
JR

Avec quel utilisateur te connectes-tu en SFTP? Quel est le véritable, verbatim, message d’erreur ?


Mon idée derrière la question : tu as dû recevoir un mail t’expliquant comment te connecter en SFTP, avec l’id de l’app my_webapp si c’est ta première, par exemple, et le mot de passe généré. Si tu ne l’as pas, il est dans /etc/yunohost/apps/my_webapp/settings.yml

Je me connecte en utilisant l’utilsateur my_webapp avec le mot de passe que j’ai entré à l’installation, comme c’est indiqué sur la page installée par défaut sur Custom Webapp.

Sur Filezilla j’ai le message d’erreur suivant quand j’essaye de me connecter :

 Erreur :         FATAL ERROR: Connection reset by peer
 Erreur :         Impossible d‘établir une connexion au serveur

Et dans les logs j’ai ça :

Jan 14 13:53:12 yuno sshd[25727]: fatal: bad ownership or modes for chroot directory "/var/www/my_webapp"

Et tu arrives à te connecter en ligne de commande?

sftp -P 22 my_webapp@TON_DOMAINE

Peux-tu partager le résultat de

ls -la /var/www/my_webapp
ls -la /var/

En fait moi aussi j’ai eu le même soucis avec filezilla. J’ai dû me connecter avec l’utilisateur root juste pour uploader vers my_webapp.

Non, impossible de me connecter en ligne de commande aussi.

client_loop: send disconnect: Broken pipe
Connection closed

Pour ls -la /var/www/my_webapp/ :

total 12
drwxrwx---+  3 root      root     4096 Jan 12 15:25 .
drwxr-xr-x+ 10 root      root     4096 Jan 12 15:25 ..
drwxr-xr-x   5 my_webapp www-data 4096 Jan 14 01:46 www

et pour ls -la /var/ :

total 52
drwxr-xr-x  13 root      root     4096 Feb  9  2021 .
drwxr-xr-x  19 root      root     4096 Dec  8 09:57 ..
drwxr-xr-x   3 root      root     4096 Jan 14 06:25 backups
drwxr-xr-x  10 root      root     4096 Feb  9  2021 cache
drwxr-xr-x  36 root      root     4096 Feb  9  2021 lib
drwxrwsr-x   2 root      staff    4096 Nov 22  2020 local
lrwxrwxrwx   1 root      root        9 Jan 27  2021 lock -> /run/lock
drwxr-xr-x  12 root      root     4096 Jan 14 00:00 log
drwxrwsr-t   3 root      mail     4096 Feb  9  2021 mail
drwxr-xr-x   2 root      root     4096 Jan 27  2021 opt
lrwxrwxrwx   1 root      root        4 Jan 27  2021 run -> /run
drwxr-xr-x   5 root      root     4096 Feb  9  2021 spool
drwxrwxrwt   7 root      root     4096 Jan 14 17:39 tmp
drwxr-xr-x+ 10 root      root     4096 Jan 12 15:25 www
drwxr-x---  12 metronome www-data 4096 Jan 12 15:19 xmpp-upload

Essayons de faire causer sftp un peu plus:

sftp -v -P 22 my_webapp@TON_DOMAINE

PS: Je suppose ici que tu n’as pas touché au port SSH par défaut, 22.

OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug1: Connecting to xxxxxx.xxxxxx.fr port 22.
debug1: Connection established.
debug1: identity file /Users/xxxx/.ssh/id_rsa type -1
debug1: identity file /Users/xxxx/.ssh/id_rsa-cert type -1
debug1: identity file /Users/xxxx/.ssh/id_dsa type -1
debug1: identity file /Users/xxxx/.ssh/id_dsa-cert type -1
debug1: identity file /Users/xxxx/.ssh/id_ecdsa type -1
debug1: identity file /Users/xxxx/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/xxxx/.ssh/id_ed25519 type -1
debug1: identity file /Users/xxxx/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/xxxx/.ssh/id_xmss type -1
debug1: identity file /Users/xxxx/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1 Debian-10+deb10u2
debug1: match: OpenSSH_7.9p1 Debian-10+deb10u2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to xxxx.xxxx.fr:22 as 'my_webapp'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:xxxxxxxxxxxxxxxxxxxx
debug1: Host 'xxxx.xxxx.fr' is known and matches the ECDSA host key.
debug1: Found key in /Users/xxxx/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /Users/xxxx/.ssh/id_rsa 
debug1: Will attempt key: /Users/xxxx/.ssh/id_dsa 
debug1: Will attempt key: /Users/xxxx/.ssh/id_ecdsa 
debug1: Will attempt key: /Users/xxxx/.ssh/id_ed25519 
debug1: Will attempt key: /Users/xxxx/.ssh/id_xmss 
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
Debian GNU/Linux 10
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/xxxx/.ssh/id_rsa
debug1: Trying private key: /Users/xxxx/.ssh/id_dsa
debug1: Trying private key: /Users/xxxx/.ssh/id_ecdsa
debug1: Trying private key: /Users/xxxx/.ssh/id_ed25519
debug1: Trying private key: /Users/xxxx/.ssh/id_xmss
debug1: Next authentication method: password
my_webapp@xxxx.xxxx.fr's password: 
debug1: Authentication succeeded (password).
Authenticated to xxxx.xxxx.fr ([xx.xxx.xxx.xxx]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
client_loop: send disconnect: Broken pipe
Connection closed

Le même problème a été indiqué sur GitHub il y a quelques heures, t’es pas le seul il semblerait: sftp connection doesn't work after webapp creation · Issue #79 · YunoHost-Apps/my_webapp_ynh · GitHub.

Mon log, après le password request:

my_webapp@[...]'s password: 
Authenticated to [...] using "password".
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: filesystem full
client_loop: send disconnect: Broken pipe
Connection closed                                                                                                                                                                             

Je peux me connecter en admin (sftp -P 22 admin@...), mais:

  • erreur Couldn't canonicalize: Permission denied quand j’essaie d’accèder à /var/www/my_webapp/www
  • erreur scp: /var/www/my_webapp/www: Permission denied quand j’essaie d’uploader un fichier avec scp -P22 file.html admin@[...]:/var/www/my_webapp/www

sudo ls -la /var/www/my_webapp/:

total 12
drwxrwx---+ 3 root      root     4096 Jan 17 10:43 .
drwxr-xr-x+ 8 root      root     4096 Jan 17 10:43 ..
drwxrwxrwx  2 my_webapp www-data 4096 Jan 17 10:43 www

Le “Manual Fix” proposé sur GitHub règle bien le problème de la connexion SFTP avec l’utilisateur de my_webapp, mais on ne peut rien uploader.

Ça ne règle pas non plus le problème du dossier /uploads/ que j’expose dans le premier message.