Liens symboliques vs point de montage
Résolu
salut a tous,
Je constate un comportement etrange en utilisant les liens symboliques vers les dossiers.
Je serais ravi que quelqu'un puisse m'eclairer.
J'ai cree un repertoire /var/www/test qui appartient a root et test. Ces derniers ont tous les droits sur le repertoire qui par contre est interdit a tout le monde. Moi meme (santiago), j'appartiens au groupe test. J'ai donc tous les droits sur /var/www/test.
Dans mon repertoire personnel (/home/santiago), j'ai cree 2 liens vers /var/www/test de deux manieres differentes : Un lien symbolique (testln) et un point de montage (testmt). Je constate que je peux utiliser ces liens de maniere transparente :
Du point de vu du shell, qu'on utilise le lien symbolique ou le point de montage, on a vraiment l'impression de rester dans le repertoire chroot.
Pourtant, lorsque j'utilise le ftp, je n'obtiens pas les meme resultats :
Autrement dit, il n'est pas possible de suivre les liens symboliques en ftp.
Est ce normal ?
Comment rendre le suivi des liens possible ?
Merci d'avance
Santiago
Je constate un comportement etrange en utilisant les liens symboliques vers les dossiers.
Je serais ravi que quelqu'un puisse m'eclairer.
J'ai cree un repertoire /var/www/test qui appartient a root et test. Ces derniers ont tous les droits sur le repertoire qui par contre est interdit a tout le monde. Moi meme (santiago), j'appartiens au groupe test. J'ai donc tous les droits sur /var/www/test.
$ ls -l /var/www/ total 8 drwxr-xr-x 2 root root 4096 2008-11-11 01:24 apache2-default drwxrws--x 2 root test 4096 2008-11-11 01:25 test
Dans mon repertoire personnel (/home/santiago), j'ai cree 2 liens vers /var/www/test de deux manieres differentes : Un lien symbolique (testln) et un point de montage (testmt). Je constate que je peux utiliser ces liens de maniere transparente :
$ ln -s /var/www/test/ testln $ mkdir testmount $ sudo mount --bind /var/www/test/ testmt/ $ ls -l lrwxrwxrwx 1 santiago santiago 14 2008-11-11 01:25 testln -> /var/www/test/ drwxrws--x 2 root test 4096 2008-11-11 01:36 testmt $ cd testln/ $ pwd /home/santiago/testln $ cd ../testmt/ $ pwd /home/santiago/testmt
Du point de vu du shell, qu'on utilise le lien symbolique ou le point de montage, on a vraiment l'impression de rester dans le repertoire chroot.
Pourtant, lorsque j'utilise le ftp, je n'obtiens pas les meme resultats :
ftp> pwd 257 "/home/santiago" is current directory. ftp> ls 200 PORT command successful 150 Opening ASCII mode data connection for file list lrwxrwxrwx 1 santiago santiago 14 Nov 11 00:25 testln -> /var/www/test/ drwxrws--x 2 root test 4096 Nov 11 00:36 testmount 226 Transfer complete. ftp> cd testln/ 550 testln: No such file or directory ftp> cd testmount/ ftp> pwd 257 "/home/santiago/testmount" is current directory. ftp> cd /var/www/test ftp> pwd 257 "/var/www/test" is current directory.
Autrement dit, il n'est pas possible de suivre les liens symboliques en ftp.
Est ce normal ?
Comment rendre le suivi des liens possible ?
Merci d'avance
Santiago
A voir également:
- Liens symboliques vs point de montage
- Montage video windows - Guide
- Notice de montage pdf - Guide
- Point de suite word - Guide
- Udp vs tcp - Guide
- Point de restauration - Guide
9 réponses
A priori ça ne me choque pas que tu ne puisses pas suivre un lien symbolique. Intuitivement ça doit être pour éviter qu'un utilisateur ftp ne sorte du root directory du serveur ftp.
Je n'ai pas lu en détail mais ceci pourrait peut être expliqué la raison :
http://www.castaglia.org/proftpd/doc/contrib/ProFTPD-mini-HOWTO-Chroot.html
Quoiqu'il en soit je te conseille plutôt de recourir à des mount bind pour construire ton arborescence ftp plutôt qu'à des liens symboliques. Exemple dans /etc/fstab (ici tout se passe comme si le contenu de /mnt/vfat/ftp était également dans /home/ftp, sachant qu'on peut agir indifféremment sur l'un ou l'autre) :
Dans cet exemple, je suppose que la racine du serveur ftp est /home/ftp.
Je pense que tu aller plus loin et construire en plusieurs ligne de fstab toute ton arborescence si le contenu du serveur ftp est dispersé du moment que le répertoire cible dans lequel tu montes ton répertoire source existe. Ainsi tu évites complètement la création de lien symbolique.
Pour plus de détails, je pense que tu devrais te promener sur le site de proftpd, sur lequel de nombreux cas d'utilisations sont décrits :
http://www.proftpd.org/
Une autre approche complètement différente et qui m'a fait abandonné ftp, c'est ssh. En effet, à partir du moment ou la personne se connecte en ssh il n'y a plus vraiment de contraintes comme les liens symboliques etc.
- L'inconvénient c'est que tu dois créer un compte sur la machine et éventuellement être vigilant sur les droits (en particulier si tu veux qu'on évite de fouiner dans ton /home). Il reste toujours possible de ne pas laisser de shell à ce genre d'utilisateurs (cf /etc/passwd).
- L'avantage c'est que c'est simple à mettre en oeuvre et plus sûre que ftp. Le client doit de son côté utiliser un client ssh (par exemple winscp sous windows, fish:// dans konqueror ou dolphin sous KDE etc...) ou s'il est sous linux utiliser la commande scp.
Bonne chance
Je n'ai pas lu en détail mais ceci pourrait peut être expliqué la raison :
http://www.castaglia.org/proftpd/doc/contrib/ProFTPD-mini-HOWTO-Chroot.html
Quoiqu'il en soit je te conseille plutôt de recourir à des mount bind pour construire ton arborescence ftp plutôt qu'à des liens symboliques. Exemple dans /etc/fstab (ici tout se passe comme si le contenu de /mnt/vfat/ftp était également dans /home/ftp, sachant qu'on peut agir indifféremment sur l'un ou l'autre) :
/mnt/vfat/ftp /home/ftp none bind 0 0
Dans cet exemple, je suppose que la racine du serveur ftp est /home/ftp.
Je pense que tu aller plus loin et construire en plusieurs ligne de fstab toute ton arborescence si le contenu du serveur ftp est dispersé du moment que le répertoire cible dans lequel tu montes ton répertoire source existe. Ainsi tu évites complètement la création de lien symbolique.
Pour plus de détails, je pense que tu devrais te promener sur le site de proftpd, sur lequel de nombreux cas d'utilisations sont décrits :
http://www.proftpd.org/
Une autre approche complètement différente et qui m'a fait abandonné ftp, c'est ssh. En effet, à partir du moment ou la personne se connecte en ssh il n'y a plus vraiment de contraintes comme les liens symboliques etc.
- L'inconvénient c'est que tu dois créer un compte sur la machine et éventuellement être vigilant sur les droits (en particulier si tu veux qu'on évite de fouiner dans ton /home). Il reste toujours possible de ne pas laisser de shell à ce genre d'utilisateurs (cf /etc/passwd).
- L'avantage c'est que c'est simple à mettre en oeuvre et plus sûre que ftp. Le client doit de son côté utiliser un client ssh (par exemple winscp sous windows, fish:// dans konqueror ou dolphin sous KDE etc...) ou s'il est sous linux utiliser la commande scp.
Bonne chance
salut mamiemando,
mon probleme est resolu si on peut dire.
en realite, je ne faisais que porter une reflexion theorique sur les differentes manieres de lier des repertoires :
1) hard link
2) symbolic link
3) mount point
D'emblee, j'ai decouvert que les hard links etaient interdits sur les repertoires.
Je connaissais bien les mount point puisque justement c'est ce que j'utilisais depuis toujours. Cependant on m'a un jour reproche cette methode et recommande les symbolic links. C'est la que j'ai entrepris de les comparer dans tous les usages que j'en faisais (notament ftp).
Comme je l'ai demontre dans ma question, symbolic links et mount points sont suivis de maniere tout a fait transparente dans le shell (en ssh). En ftp, mes conclusions etaient plus mitigees puisque je me suis rendu compte que le probleme ne venait pas du protocole ou du serveur, mais du client.
1) avec ftp (GNU/linux), les liens sont suivis, mais de maniere non transparente :
2) avec lftp (GNU/linux), les liens sont suivis de maniere transparente :
Bien entendu, lorsque les liens sont suivis de maniere non transparente, se pose le probleme du home directory. Si l'utilisateur est cantonne a son home directory, les symbolic links externes ne seront pas suivis.
Bonne journee
Santiago
mon probleme est resolu si on peut dire.
en realite, je ne faisais que porter une reflexion theorique sur les differentes manieres de lier des repertoires :
1) hard link
2) symbolic link
3) mount point
D'emblee, j'ai decouvert que les hard links etaient interdits sur les repertoires.
Je connaissais bien les mount point puisque justement c'est ce que j'utilisais depuis toujours. Cependant on m'a un jour reproche cette methode et recommande les symbolic links. C'est la que j'ai entrepris de les comparer dans tous les usages que j'en faisais (notament ftp).
Comme je l'ai demontre dans ma question, symbolic links et mount points sont suivis de maniere tout a fait transparente dans le shell (en ssh). En ftp, mes conclusions etaient plus mitigees puisque je me suis rendu compte que le probleme ne venait pas du protocole ou du serveur, mais du client.
1) avec ftp (GNU/linux), les liens sont suivis, mais de maniere non transparente :
ftp> ls 200 PORT command successful 150 Opening ASCII mode data connection for file list lrwxrwxrwx 1 santiago santiago 19 Nov 12 15:15 testln -> /var/www/test/ 226 Transfer complete. ftp> cd testln 250 CWD command successful ftp> pwd 257 "/var/www/test" is current directory.
2) avec lftp (GNU/linux), les liens sont suivis de maniere transparente :
lftp> ls lrwxrwxrwx 1 santiago santiago 19 Nov 12 15:15 testln -> /var/www/test/ lftp> cd testln cd ok, cwd=/home/santiago/testln lftp> pwd ftp://santiago@xxx/%2Fhome/santiago/testln
Bien entendu, lorsque les liens sont suivis de maniere non transparente, se pose le probleme du home directory. Si l'utilisateur est cantonne a son home directory, les symbolic links externes ne seront pas suivis.
Bonne journee
Santiago
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Merci pour toutes ces précisions ! En ce qui me concerne je fais surtout du ssh et quand je dois faire du ftp, j'utilise lftp, c'est le plus simple ;-) Bref après à toi de voir ce qui te convient le mieux !
moi ce qui me convient le mieux, c'est le ssh, mais j'ai des collaborateurs a qui j'offre un espace d'hebergement sur mon serveur et 1) il ne savent pas utiliser ssh 2) je ne veux pas qu'ils se connectent via un shell.
si tu t'interesse au scripts, j'en ai poste un que j'aimerais faire tester pour detecter les erreurs.
si tu t'interesse au scripts, j'en ai poste un que j'aimerais faire tester pour detecter les erreurs.
Concrètement ils ont juste à installer winscp s'ils sont sous windows, sous linux c'est directement intégré comme je disais auparavant.
Pour éviter qu'ils puissent avoir un shell, il suffit :
1) de leur créer un compte (via les commandes adduser ou useradd)
2) de corriger /etc/passwd de sorte à ce qu'ils aient /bin/false au lieu de /bin/bash.
Bonne chance
Pour éviter qu'ils puissent avoir un shell, il suffit :
1) de leur créer un compte (via les commandes adduser ou useradd)
2) de corriger /etc/passwd de sorte à ce qu'ils aient /bin/false au lieu de /bin/bash.
Bonne chance
Mes collaborateurs ont deja tous un compte dont le shell est /bin/false.
Il y a 2 raisons pour lesquelles je ne leur propose pas winscp
1) Il connaissent tous un client ftp (et y sont habitues)
2) Je n'arrive pas a les cantonner a leur home directory avec winscp
Si tu as plus d'info sur le 2e point, ca m'interesse.
Il y a 2 raisons pour lesquelles je ne leur propose pas winscp
1) Il connaissent tous un client ftp (et y sont habitues)
2) Je n'arrive pas a les cantonner a leur home directory avec winscp
Si tu as plus d'info sur le 2e point, ca m'interesse.
Pour (1) il faut bien voir que winscp est très proche de filezilla ou tout autre client ftp.
Pour (2) essaye de changer les droits sur ".." pour leur éviter de remonter l'arborescence et les cantonner dans leur home directory.
Si le répertoire que tu chmod ne leur appartient pas tu peux mettre des droits moins réstrictif, car dans cet exemple seul root pourra accéder à "..".
Bonne chance
Pour (2) essaye de changer les droits sur ".." pour leur éviter de remonter l'arborescence et les cantonner dans leur home directory.
(mando@aldur) (~/pouet) $ chmod 000 .. (mando@aldur) (~/pouet) $ cd .. bash: cd: ..: Permission non accordée
Si le répertoire que tu chmod ne leur appartient pas tu peux mettre des droits moins réstrictif, car dans cet exemple seul root pourra accéder à "..".
Bonne chance
