l'utilisateur "a", depuis son shell bash, lance su.
le shell fork et execute su.
tu as deux processus : le shell est toujours là, et le su.
l'utilisateur associé au processus su passe à root (ou à un autre utilisateur), puis su invoque un shell.
tu as trois processus : le shell d'origine qui appartient toujours à "a", qui attend la fin de su, le su qui appartient à root qui attend la fin du shell invoqué, et le shell invoqué (qui appartient à root aussi donc) qui attend que tu tappes des commandes.
ce n'est pas la manière que tu avais imaginée, mais ça fait du sens du point de vue unix :
- si le shell d'origine passait à root, il faudrait une notion de pile de changement d'utilisateur, ou au moins une notion de "sortie" de changement d'utilisateur, qui n'existe pas
- tout est basé sur la notion de processus, la seule entorse à ma connaissance est fork, tout le reste agit sur le processus en cours, en particulier ici on invoque "su" avec l'appel système exec après fork, puis on change l'identité du processus avec les appels système setgid et setuid
[^] # Re: Sois plus clair.
Posté par gc . En réponse au message pas de su en bash ?. Évalué à 1.
l'utilisateur "a", depuis son shell bash, lance su.
le shell fork et execute su.
tu as deux processus : le shell est toujours là, et le su.
l'utilisateur associé au processus su passe à root (ou à un autre utilisateur), puis su invoque un shell.
tu as trois processus : le shell d'origine qui appartient toujours à "a", qui attend la fin de su, le su qui appartient à root qui attend la fin du shell invoqué, et le shell invoqué (qui appartient à root aussi donc) qui attend que tu tappes des commandes.
ce n'est pas la manière que tu avais imaginée, mais ça fait du sens du point de vue unix :
- si le shell d'origine passait à root, il faudrait une notion de pile de changement d'utilisateur, ou au moins une notion de "sortie" de changement d'utilisateur, qui n'existe pas
- tout est basé sur la notion de processus, la seule entorse à ma connaissance est fork, tout le reste agit sur le processus en cours, en particulier ici on invoque "su" avec l'appel système exec après fork, puis on change l'identité du processus avec les appels système setgid et setuid