Joël Bertrand, le 2018-02-13 : > Étienne Mollier a écrit : > > Est-ce que le problème se présentait si vous aviez l'un des > > bash codé en dur dans votre entrée NIS, en vous loguant en > > sftp sur le système correspondant ? > > Si je mets l'un des bash en dur, ça fonctionne sur le > poste en question (mais pas sur les autres...).
D'accord, on peut écarter ce problème de sortie texte. > La question que je me suis posé est de savoir si > /etc/shells doit contenir mon script ou non. Visiblement non > puisque l'exécutable réel est le vrai shell. Dans le doute, je l'y mettrais tout de même. Si j'en juge par le manuel, les vénérables dæmons ftp pouvaient interdire l'accès s'ils ne trouvaient pas le shell de l'utilisateur dans la liste fournie par le fichier /etc/shells. man 5 shells : > Be aware that there are programs which consult this file > to find out if a user is a normal user; for example, FTP > daemons traditionally disallow access to users with > shells not included in this file. Ça n'apparaît pas dans le manuel de sftp, mais rien ne dit qu'il n'a pas hérité, ou n'héritera pas, de ce comportement. François Lafont, le 2018-02-13 : > On 02/12/2018 04:01 PM, BERTRAND Joël wrote: > > Je me suis cru malin en écrivant : > > > > #!/bin/sh > > if [ `uname -s` = Linux ]; then > > /bin/bash > > else > > if [ -e /usr/pkg/bin/bash ]; then > > /usr/pkg/bin/bash > > else > > /bin/sh > > fi > > fi > > exit 0 > > Ce script ne prend en charge aucun argument alors qu'en > principe c'est le cas d'un shell. Éventuellement tenter de > faire ça (où "$@" permet de reprendre les arguments passés au > script) : > > ------------------------ > #!/bin/sh > > if [ `uname -s` = Linux ]; then > /bin/bash "$@" > else > if [ -e /usr/pkg/bin/bash ]; then > /usr/pkg/bin/bash "$@" > else > /bin/sh "$@" > fi > fi > ------------------------ > > Enfin si bash est correctement installé sur le système, la > logique voudrait qu'il soit dans le PATH. Dans ce cas, je > tenterais plutôt : > > if which bash >/dev/null > then > bash "$@" > else > /bin/sh "$@" > fi Bien vu, sans le transfert des arguments, l'option de login shell « -l » ne peut pas être transférée par le wrapper au shell du système. Il y a fort à parier que ça aide à résoudre pas mal de problèmes. :-) Pour aller encore plus loin, il est possible de transférer complètement la main au shell et obtenir du même coup la remontée des éventuels codes d'erreurs en ajoutant des directives exec. Cela donnerait : #!/bin/sh if which bash >/dev/null then exec bash "$@" fi exec /bin/sh "$@" À plus, -- Étienne Mollier <etienne.moll...@mailoo.org>