Re: comportement étrange en console
2012-03-10 23:44:28 +0100, luc schimpf:
[...]
> 23:42 root@au-ptit-bon-air:/home/luc# ps -fjp "$$"
> UID PID PPID PGID SID C STIME TTY TIME CMD
> root 22694 22672 22694 22694 0 23:42 ? 00:00:00 /bin/bash
>
> 23:42 root@au-ptit-bon-air:/home/luc# pstree -Alusp $$
> init(1)---yakuake(3321,luc)---bash(9617)---su(22672,root)---bash(22694)---pstree(22705)
[...]
Ce que se passe est que quelquechose demarre une nouvelle
session.
22694 est session-leader, mais pas de la session qui controle le
terminal (ca serait plutot 9617), donc il ne peut pas faire un
tcsetpgrp(3) sur ce terminal pas plus qu'un process dans un
autre yakuake ne le pourrait.
A priori, je ne vois que "su" qui puisse faire ca avant
d'executer bash, ou quoi que ce soit que su execute qui ensuite
execute bash. Ce n'est pas un comportement que j'aie observé
auparavant.
Mais je suis a la version 4.1.4 du package "login", et je
remarque que les changements de la version 4.1.5 introduisent:
* New upstream release: ▒
- su: Fix possible tty hijacking by dropping the controlling terminal when ▒
executing a command (CVE-2005-4890). Closes: #628843 ▒
Et effectivement, apres upgrade, j'ai le meme comportement et je
vois le "setsid(2)" de "su" si je fais "su -c bash" (mais pas
"su" tout court, ou "su -s /bin/bash").
Voir http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628843
pour les raisons du changement.
Donc, c'est une feature et pas un bug, mais une annoying feature
pour parer un probleme de securité improbable.
Le work-around: "su -s"
--
Stephane
Reply to: