Shell

Le
BERTRAND Jo=c3=abl
Bonjour à tous,

Considérons mon infrastructure. J'ai un serveur principal qui tourne
sous NetBSD (serveur de boot, serveur NIS/NFSv3) et qui se débrouille
pour exporter tout ce qu'il faut à un certain nombre de stations
diskless. Ces stations fonctionnent sous FreeBSD et Linux/Debian.

Problème : bash est par défaut sous Debian dans /bin/bash. Sous
FreeBSD, il se trouve dans /usr/local/bin/bash. Sous NetBSD, c'est dans
/usr/pkg/bin/bash.

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

et en déclarant ce script comme shell de l'utilisateur.

J'arrive à me connecter à n'importe quelle machine en ssh sans aucun
problème. Mais il m'est impossible d'effectuer en sftp.

Je suppose qu'il existe un mécanisme dans ssh spécifique à sftp pour
refuser cette astuce mais je sèche.

Une idée ?

Bien cordialement,

JKB
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Gabriel Moreau
Le #26464393
#!/bin/sh

Via env, cela donne quoi ?
#!/usr/bin/env bash
gaby
--
Gabriel Moreau - IR CNRS http://www.legi.grenoble-inp.fr
LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
Domaine Universitaire, CS 40700, 38041 Grenoble Cedex 9, France
mailto: tel:+33.476.825.015
Répondre en citant
BERTRAND Jo=c3=abl
Le #26464401
Gabriel Moreau a écrit :
#!/bin/sh

Via env, cela donne quoi ?
#!/usr/bin/env bash

Pareil. Mais /bin/sh étant présent sur tous les systèmes, je doute que
ce soit le fautif (d'autant que je peux me connecter par ssh sur toutes
les machines).
Bien cordialement,
JKB
Répondre en citant
=c3
Le #26464429
On 02/12/2018 04:01 PM, BERTRAND Joël wrote:
J'arrive à me connecter à n'importe quelle machine en ssh
sans aucun problème. Mais il m'est impossible d'effectuer en
sftp.

Bonsoir,
Au risque de passer à côté du sujet, j'ai rencontré un problème
similaire. Si j'édite le fichier de ressource de mon shell pour
lui faire afficher quelque chose, alors ça me plante sftp, mais
pas ssh :
$ head -n2 ~/.bashrc
#!/bin/bash
echo plante
$ ssh localhost
plante
$ echo 'Dans une session ssh... :)'
Dans une session ssh... :)
$ sftp localhost
Received message too long 1886151022
$ echo 'Pas dans une session sftp... :('
Pas dans une session sftp... :(
« Il suffit » d'enlever tout ce qui pourrait écrire dans stdout
pour corriger le problème. Si j'efface mon « echo plante »,
alors le problème est corrigé :
$ head -n2 ~/.bashrc
#!/bin/bash
$ sftp localhost
Connected to localhost.
sftp>
Sauf que, et à moins que j'ai loupé quelque chose, votre script
ne devrait pas engendrer de message dans stdout. 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 ?
À plus,
--
Étienne Mollier
Répondre en citant
BERTRAND Jo=c3=abl
Le #26464475
Étienne Mollier a écrit :
On 02/12/2018 04:01 PM, BERTRAND Joël wrote:
J'arrive à me connecter à n'importe quelle machine en ssh
sans aucun problème. Mais il m'est impossible d'effectuer en
sftp.

Bonsoir,
Au risque de passer à côté du sujet, j'ai rencontré un problème
similaire. Si j'édite le fichier de ressource de mon shell pour
lui faire afficher quelque chose, alors ça me plante sftp, mais
pas ssh :
$ head -n2 ~/.bashrc
#!/bin/bash
echo plante
$ ssh localhost
plante
$ echo 'Dans une session ssh... :)'
Dans une session ssh... :)
$ sftp localhost
Received message too long 1886151022
$ echo 'Pas dans une session sftp... :('
Pas dans une session sftp... :(
« Il suffit » d'enlever tout ce qui pourrait écrire dans stdout
pour corriger le problème. Si j'efface mon « echo plante »,
alors le problème est corrigé :
$ head -n2 ~/.bashrc
#!/bin/bash
$ sftp localhost
Connected to localhost.
sftp>
Sauf que, et à moins que j'ai loupé quelque chose, votre script
ne devrait pas engendrer de message dans stdout.

Effectivement, le script en question ne renvoie rien sur stdout (ni sur
stderr du reste).
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...).
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.
Bien cordialement,
JKB
Répondre en citant
Francois Lafont
Le #26464493
Bonjour,
Bonjour,
Pardon, j'ai envoyé mon message en privé au lieu de l'envoyer sur la liste.
Je reposte.
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
--
François Lafont
Répondre en citant
Gabriel Moreau
Le #26464501
if [ `uname -s` = Linux ]; then

Je remplace juste ce test par celui-là
if [ "$(uname -s)" = Linux ]; then
cela permet d'assurer à 100% d'avoir une vraie chaîne à gauche
et sur le principe, le $() est plus sur que le `` (car récursif).
gabriel
--
Gabriel Moreau - IR CNRS http://www.legi.grenoble-inp.fr
LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
Domaine Universitaire, CS 40700, 38041 Grenoble Cedex 9, France
mailto: tel:+33.476.825.015
Répondre en citant
=c3
Le #26464586
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
Répondre en citant
Francois Lafont
Le #26464601
On 02/13/2018 09:03 PM, Étienne Mollier wrote:
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 "$@"

Ah oui, tout à fait, c'est encore mieux avec le exec. :)
--
François Lafont
Répondre en citant
BERTRAND Jo=c3=abl
Le #26464611
Francois Lafont a écrit :
On 02/13/2018 09:03 PM, Étienne Mollier wrote:
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 "$@"

Ah oui, tout à fait, c'est encore mieux avec le exec. :)


Bonsoir à tous,
Je vais regarder tout cela attentivement et ferai un retour dès que
possible (j'ai un truc beaucoup plus important sur le feu).
Bien cordialement,
--
http://www.systella.fr
Répondre en citant
Publicité
Poster une réponse
Anonyme