Message d'erreur "500 OOPS: vsftpd: refus de s'exécuter avec une racine accessible en écriture dans chroot ()" - garder l'utilisateur emprisonné


19

Jusqu'à présent, je n'ai pas pu garder un utilisateur FTP emprisonné dans le répertoire de leur site Web. Existe-t-il une solution qui corrige ce bogue et garde l'utilisateur emprisonné dans son répertoire?

Mes paramètres vsFTPd que j'ai modifiés:

listen_port=9000
Set: anonymous_enable=NO
Uncomment: local_enable=YES
Uncomment: write_enable=YES
Uncomment: local_umask=022
Set: connect_from_port_20=NO
Uncomment: idle_session_timeout=600
Uncomment: data_connection_timeout=120
Comment out: #ftpd_banner=Welcome to blah FTP service. [should be on line 104]
Added: banner_file=/etc/issue.net
Uncomment: chroot_local_user=YES
Uncomment: chroot_local_user=YES
Uncomment: chroot_list_enable=YES
Uncomment : chroot_list_file=/etc/vsftpd.chroot_list

À la fin du fichier, j'ai ajouté:

# Show hidden files and the "." and ".." folders.
# Useful to not write over hidden files:
force_dot_files=YES

# Hide the info about the owner (user and group) of the files.
hide_ids=YES

# Connection limit for each IP address:
max_per_ip=10

# Maximum number of clients:
max_clients=5

# FTP Passive Settings
pasv_enable=YES
#If your listen_port is 9000 set this range to 7500 and 8500
pasv_min_port=[port range min]
pasv_max_port=[port range max]

L'utilisateur en question mybloguser,, est emprisonné dans le répertoire de son site Web sous /srv/www/mybloget cet utilisateur ne fait pas partie du nano /etc/vsftpd.chroot_listfichier. Le répertoire personnel de l'utilisateur est également celui /srv/www/myblogqui fonctionnait auparavant.

J'ai essayé la allow_writeable_chroot=YESsolution qui n'a pas fonctionné et j'ai complètement cassé vsFTPd.

J'ai essayé:

Comment pouvons-nous à la fois corriger cette erreur et garder l'utilisateur emprisonné dans son répertoire personnel?


D'une certaine manière, pour moi, au moins avec les utilisateurs ftp "virtuels", l'ajout du paramètre allow_writeable_chroot=YESétait suffisant et fonctionnait "comme prévu" FWIW ...
rogerdpack

Réponses:


18

Pour VSFTPD 3,

  1. Aller à: /etc/vsftpd.conf
  2. et ajoutez ceci:

    allow_writeable_chroot=YES
    

    Ajoutez-le simplement s'il n'existe pas encore.

  3. Redémarrez le service vsftpd:

    service vsftpd restart
    

Et ça devrait marcher.


3
L'intervenant déclare en fait qu'il a déjà essayé cela et que cela n'a pas fonctionné, ce n'est donc pas une réponse à sa question.
Rendez-vous

2
Où puis-je lire les implications de sécurité de ce choix?
flickerfly

travaillé pour moi (cela a également été mentionné dans le commentaire de la réponse acceptée)
Sverre

16

La vraie solution de ce problème: le dossier personnel de l'utilisateur ne doit pas être accessible en écriture mais seulement lisible.

Donc, si le site utilisateur est dans le dossier cat/example.com/http/, le dossier catdoit avoir chmod 555et tout ira bien.


12
Ça n'a aucun sens. Le répertoire de l'utilisateur ne doit pas être accessible en écriture ???
Kevin Bowen

6
Comment exactement l'utilisateur est-il censé TÉLÉCHARGER des fichiers s'il ne peut pas écrire?!
Cerin

Cela fonctionne bien pour un ftp anonyme sans droits de téléchargement, merci!
palacsint

droite! maintenant c'est ok
user1406691

5
Cela fonctionne parfaitement! Créez simplement une maison pour l'utilisateur avec chmod 555 puis, à l'intérieur, créez une maison pour le site Web (ou les sites Web), avec chmod 755 ou celui dont vous avez besoin: tout fonctionnera et l'utilisateur aura des autorisations d'écriture.
lucaferrario

13

Après un examen plus approfondi de ce message, dans les commentaires, un package a été publié qui a résolu mon problème. Vous pouvez le rechercher par mon nom ou par la documentation "Marks": http://www.benscobie.com/fixing-500-oops-vsftpd-refusing-to-run-with-writable-root-inside-chroot/ . Voici mes détails sur la façon dont j'ai résolu ce problème.

LES UTILISATEURS SONT TOUJOURS JAILÉS À LEURS RÉPERTOIRES À DOMICILE !!!

# ------------------------------------------------------------------------------
# SETUP FTP USERS --------------------------------------------------------------
# ------------------------------------------------------------------------------

# create the ftp users and lock them to the website directories
useradd -d /srv/www/[website/appname] -m [ftp user name]

# set the ftp account passwords
passwd [ftp user name]

# add the ftp users to the www-data user/group
adduser [ftp user name] www-data

# BUG FIX: 500 OOPS: vsftpd: refusing to run with writable root inside chroot()
sudo add-apt-repository ppa:thefrontiergroup/vsftpd
sudo apt-get update
sudo apt-get install vsftpd

# Edit the vsftpd.conf and append this setting to the end of the file to keep users' jailed!
nano /etc/vsftpd.conf

# add all of the text between the starting [[ and ending ]]
# [[

# Keep non-chroot listed users jailed
allow_writeable_chroot=YES

# ]]

# restart the service for changes to take effect
sudo service vsftpd restart

#test ftp via secondary terminal window:
ftp [ftp user name]@[server ipaddress] [ftp port]

11
Remarque: la solution de Chris ajoutera un serveur de packages tiers à votre liste de référentiels! Pourquoi installer un serveur FTP sécurisé et chrooté lorsque vous acceptez aveuglément des packages de logiciels étrangers à installer sur votre système. (Chris: Je ne pense pas que vous en profiterez, mais utiliser cette solution à
mon humble avis

1
avez-vous une meilleure approche pour résoudre ce dilemme @reto? Cela a été un petit gâchis à résoudre. Merci de votre aide.
Chris Hough

s'il y a un paquet mis à jour de la distribution, j'essaierais de l'utiliser. La plupart des distributions fournissent des rétroportages pour les anciennes versions. Si ce n'est pas possible, j'obtiendrais la source du développeur d'origine et la construirais moi-même. S'il y a un patch flottant, je peux l'appliquer (généralement ils sont petits et peuvent être vérifiés manuellement).
reto

Ce fil a 12'000 vues, supposons que 5% utilisent votre solution et ont ajouté votre repo. Vous pouvez facilement ajouter une nouvelle version d'un package de base avec une porte dérobée intégrée. En une semaine, vous pourriez avoir accès à 600 systèmes. Je ne pense pas que vous feriez cela, mais l'ajout d'un référentiel tiers n'est tout simplement pas très sûr.
reto

1
Je n'avais pas besoin de mettre à jour depuis le dépôt. Pour moi, l'ajout de la ligne "allow_writeable_chroot = YES" a corrigé le bug
abumalick

7

Selon la réponse précédente "La VRAIE solution de ce problème: le dossier personnel de l'utilisateur ne doit pas être accessible en écriture uniquement en lecture.". La pensée générale est juste, mais avec une mauvaise réalisation.

Ci-dessous, je vais essayer de donner un exemple simple:

Pour commencer, nous devons construire une topologie du répertoire utilisateur:

 / home (ro)
   | -someuser (rw, 700)
         | -ftp_upload (ro, 555) - ch_rooting ici, requis en lecture seule par vsftpd :(
           | -temp (rw, 755)
           | -in_box (rw, 755)
           | -out_box (rw, 755)

vsftpd.conf coupe:

# Activer le chrootage
chroot_local_user = OUI

# chroot tous les utilisateurs sauf écoutés dans chroot_list
chroot_list_enable = OUI

# Liste d'exceptions. Idéalement, il devrait être vide;)
chroot_list_file = / etc / vsftpd / chroot_list

# Mappez le répertoire racine ftp vers un répertoire spécifique
local_root = / home / someuser / ftp

Cette configuration fonctionne très bien avec un configuration mono-utilisateur . Pour les multi-utilisateurs, la directive "user_config_dir" doit être utilisée en plus.

** MISE À JOUR 20/09

------ **

Voici une solution de contournement délicate, pas la meilleure idée à utiliser, mais .... Si vous avez besoin d'un dossier racine ftp accessible en écriture, insérez simplement les commandes de changement d'autorisation dans les commandes de pré-démarrage et de post-démarrage.

  1. Pré-démarrage - modifiez les autorisations en lecture seule, dont le serveur a besoin (:

  2. Démarrer le serveur

  3. Post-démarrage - modifiez l'autorisation de lecture-écriture ou dont vous avez besoin.


J'ai essayé de nombreuses variantes mais je n'ai pas pu le faire fonctionner pour un serveur WP. Est-ce que cela fonctionne pour vous sur une configuration WP?
Chris Hough

regardez pour mettre à jour la section, mauby cette variante peut vous aider, ce n'est pas complètement sûr de le faire, mais si aucune autre possibilité ...
Reishin

1

C'est à peu près ce que toastboy70 a mentionné. Rendre le répertoire racine ftp affiché dans ftp.ftp et non inscriptible (/etc/vsftpd.conf): anon_root = / srv / ftp

Créez ensuite un répertoire enfant accessible en écriture: / srv / ftp / upload


0

J'avais également besoin d'ajouter ce qui suit au fichier /etc/vsftpd.conf:

seccomp_sandbox=NO

ET pas besoin du repo personnalisé !!

Et décommentez la ligne:

write_enable=YES

0

La solution simple consiste à faire comme le message d'erreur le suggère: rendre la racine non accessible en écriture et puis si vous devez activer les téléchargements, créez un sous-répertoire qui dispose d'une autorisation d'écriture. Aucun changement de configuration nécessaire.


0

Après 3 heures de recherche sur Google, j'ai réussi à utiliser Ubuntu 14.04.2 LTS VSFTPd 3. Le dossier personnel sera visible / home / vimal une fois accessible avec un client. Je me suis connecté avec vimal avec le privilège root. J'ai créé le dossier ftpShare, mais n'a pas beaucoup de sens.

sudo chown vimal:vimal /home/vimal/ftpShare/

quelques commandes utiles:

sudo nano /etc/vsftpd.conf
sudo service vsftpd restart
sudo apt-get purge vsftpd
netstat -a | grep ftp
tcp        0        0        *:ftp         *:*        LISTEN
ftp://12.345.23.xxx/  for browser login

Ci-dessus signifie que le démon ftp fonctionne

J'ai la configuration suivante:

seccomp_sandbox=no
listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
dirmessage_enable=YES
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
chroot_local_user=YES
chroot_list_enable=NO
secure_chroot_dir=/var/run/vsftpd/empty
rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
allow_writeable_chroot=YES

Une fois que FTP fonctionne, vous pouvez l'adapter à des besoins spécifiques, certains d'entre eux ont des valeurs par défaut, mais je ne me souviens pas exactement.

Erreurs vues dans le client FTP:

1. 500 OOPS: échec de prctl PR_SET_SECCOMP

Solution.

seccomp_sandbox=no    

[ajoutez-le sur la toute première ligne vsftpd.conf, après la fin de la section commentée initiale]

2. 500 OOPS: vsftpd: refus de fonctionner avec une racine accessible en écriture dans chroot ()

allow_writeable_chroot=YES

Je l'ai ajouté à la dernière ligne.


0

J'ai résolu le problème de vsFTPd refusant de s'exécuter avec une racine accessible en écriture dans chroot () sur mon serveur Ubuntu comme suit:

Je viens d'ajouter la ligne ci-dessous dans le vsftpd.conffichier:

allow_writeable_chroot=YES
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.