Lancement d'un shell comme s'il s'agissait d'une connexion

Lancement d'un shell comme s'il s'agissait d'une connexion - Shell/Batch - Programmation

Marsh Posté le 21-06-2012 à 09:51:08    

Bonjour
 
Lorsque je me connecte sur une machine Unix, j'ai mon shell (KSH) qui démarre d'une certaine façon (un "-" devant le nom du process, chargement du /etc/profile et .profile, se positionne dans la HomeDirectory du compte ...).
Mais si je le lance manuellement (depuis un autre shell), je n'ai plus ce comportement.
 
Est-il possible de lancer KSH en lui demandant de démarrer comme s'il s'agissait d'une nouvelle connexion ?
Merci :jap:  
 
(par exemple la commande "su -" le fait)

Message cité 1 fois
Message édité par mrbebert le 21-06-2012 à 09:51:31

---------------
Doucement le matin, pas trop vite le soir.
Reply

Marsh Posté le 21-06-2012 à 09:51:08   

Reply

Marsh Posté le 22-06-2012 à 20:03:27    

mrbebert a écrit :

Bonjour
 
Lorsque je me connecte sur une machine Unix, j'ai mon shell (KSH) qui démarre d'une certaine façon (un "-" devant le nom du process, chargement du /etc/profile et .profile, se positionne dans la HomeDirectory du compte ...).
Mais si je le lance manuellement (depuis un autre shell), je n'ai plus ce comportement.
 
Est-il possible de lancer KSH en lui demandant de démarrer comme s'il s'agissait d'une nouvelle connexion ?
Merci :jap:


Salut
Le /etc/profile et ~/.profile sont chargés lors de la connexion, pas lors de l'appel d'un shell.
Lors de l'appel d'un shell (que ce soit par ksh depuis la ligne de commande ou par ":sh" depuis vi), c'est le fichier /etc/kshrc puis ~/.kshrc qui sont invoqués (enfin ça dépend aussi du shell invoqué car par exemple en Bourne Again shell ce sont les fichiers /etc/bash.bashrc puis ~/.bashrc).
 
Donc cela te permet d'affiner ton administration. Si tu veux associer certaines actions à la connexion de tout le monde tu mets ces actions dans /etc/profile. Si tu veux associer ces actions à la connexion d'une seule personne tu mets ces actions dans son ~/.profile. Si tu veux associer certaines actions à l'ouverture d'un shell par quiconque tu mets ces actions dans /etc/kshrc et si tu veux associer ces actions à l'ouverture d'un shell d'un utilisateur X tu mets ces actions dans son ~/.kshrc
 

mrbebert a écrit :

(par exemple la commande "su -" le fait)


Oui, le tiret postfixé à la commande lui demande de récupérer l'environnement de l'utilisateur invoqué. Donc c'est la commande qui se charge d'aller lire et traiter les fichiers /etc/profile et autres. Tu peux toi aussi programmer un clone de su qui fait pareil (ou même mieux le récupérer chez-toi et exécuter cette copie si tu veux invoquer un shell pour toi) mais il n'existe pas d'outil de base permettant de simuler une connexion (parce que généralement cela n'est pas nécessaire vu la finesse que l'on a avec les divers fichiers cités précédemment)...

Reply

Marsh Posté le 22-06-2012 à 22:24:25    

Sve@r a écrit :


Salut
Le /etc/profile et ~/.profile sont chargés lors de la connexion, pas lors de l'appel d'un shell.
Lors de l'appel d'un shell (que ce soit par ksh depuis la ligne de commande ou par ":sh" depuis vi), c'est le fichier /etc/kshrc puis ~/.kshrc qui sont invoqués (enfin ça dépend aussi du shell invoqué car par exemple en Bourne Again shell ce sont les fichiers /etc/bash.bashrc puis ~/.bashrc).
 
Donc cela te permet d'affiner ton administration. Si tu veux associer certaines actions à la connexion de tout le monde tu mets ces actions dans /etc/profile. Si tu veux associer ces actions à la connexion d'une seule personne tu mets ces actions dans son ~/.profile. Si tu veux associer certaines actions à l'ouverture d'un shell par quiconque tu mets ces actions dans /etc/kshrc et si tu veux associer ces actions à l'ouverture d'un shell d'un utilisateur X tu mets ces actions dans son ~/.kshrc

Merci pour ces détails :jap:  
 

Sve@r a écrit :


Oui, le tiret postfixé à la commande lui demande de récupérer l'environnement de l'utilisateur invoqué. Donc c'est la commande qui se charge d'aller lire et traiter les fichiers /etc/profile et autres. Tu peux toi aussi programmer un clone de su qui fait pareil (ou même mieux le récupérer chez-toi et exécuter cette copie si tu veux invoquer un shell pour toi) mais il n'existe pas d'outil de base permettant de simuler une connexion (parce que généralement cela n'est pas nécessaire vu la finesse que l'on a avec les divers fichiers cités précédemment)...

Je pensais que c'était le shell lui même. Voila qui ne m'arrange pas :/  


---------------
Doucement le matin, pas trop vite le soir.
Reply

Marsh Posté le 24-06-2012 à 21:51:06    

mrbebert a écrit :

Voila qui ne m'arrange pas :/  


Généralement, les choses sur Unix qui ne sont pas prévues le sont parce que c'est inutile (ou contournable). Donc peut-être que si tu nous expliques ton problème initial (pour lequel tu penses que la solution est de récupérer l'environnement) on peut te proposer une autre solution...

Reply

Marsh Posté le 25-06-2012 à 13:51:10    

Ok, reprenons depuis le début :)
 
J'ai un outil qui permet de lancer une commande avec les droits d'un autre compte (une sorte de "sudo" ), que l'on l'utilise pour donner accès à des comptes applicatifs.
Actuellement, pour aller vers le compte "appli", on fait exécuter la commande "su - appli" avec le compte ... root (pour ne pas que "su" demande le mot de passe). Etre obligé de passer par root alors qu'on veut seulement aller vers "appli", c'est dommage (tout le monde se retrouve à devoir passer par root).
L'autre solution (celle vers laquelle je préférerais aller) serait de demander à exécuter "/usr/bin/ksh" avec le compte "appli". Mais dans ce cas, si le shell fonctionne bien avec le compte "appli", il n'a pas du tout récupéré son environnement :/


---------------
Doucement le matin, pas trop vite le soir.
Reply

Marsh Posté le 25-06-2012 à 15:43:18    

salut,
 

Citation :

J'ai un outil qui permet de lancer une commande avec les droits d'un autre compte (une sorte de "sudo" ), que l'on l'utilise pour donner accès à des comptes applicatifs.

quel est le problème alors ?

Citation :

Actuellement, pour aller vers le compte "appli", on fait exécuter la commande "su - appli" avec le compte ... root (pour ne pas que "su" demande le mot de passe).

pourquoi ne pas utiliser l'outil ?
 
la solution ne serait-elle pas d'utiliser sudo

Code :
  1. sudo -i -u appli

les utilisateurs autorisés sont ajoutés à un groupe X, et le groupe X est autorisé dans /etc/sudoers !

Reply

Marsh Posté le 25-06-2012 à 16:23:59    

Justement, on utilise l'outil. Et le problème, c'est que l'on passe par root au lieu d'aller directement vers le compte de destination (et donc, techniquement, on donne le droit à tout le monde de passer root). Pour la seule raison que l'on veut exécuter le sudo pour pouvoir charger l'environnement de destination.
J'aimerai donc pouvoir charger l'environnement dans le shell lancé sans être obligé de passer par le su, donc par le compte root.
(non, changer d'outil n'est pas une solution)


---------------
Doucement le matin, pas trop vite le soir.
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed