«Impossible de définir le groupe de processus de terminal» pendant que su à un autre utilisateur comme shell de connexion

Remarque: veuillez lire les informations mises à jour commençant par "MODIFIER" à mi-chemin de ce message - l'environnement et l'arrière-plan de ce problème ont changé

J'ai ici une installation standard de Debian 6.0, que j'ai décidé de passer aux référentiels de test Debian. J'ai fait cela en échangeant les références aux référentiels Squeeze dans ma sources.list pour utiliser les référentiels de test à la place.

Après l'installation du package et un redémarrage, j'obtiens l'erreur suivante lorsque j'essaie de faire appel à un autre utilisateur:

root@skaia:~# su joebloggs -
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell

Si j'omet le -, cela ne se produit pas.

Notez que les utilisateurs peuvent devenir root correctement, cela ne semble se produire qu'en passant de root à quelqu'un d'autre et en utilisant le - pour obtenir l'environnement de cet utilisateur.

Google est surtout inutile ici. Les seules choses que je peux trouver sont des références de 2011 en ce qui concerne le suxpaquet, qui semblent avoir été corrigées entre-temps.

Cela ressemble et sent très bien comme une erreur de mise à niveau, réparable en modifiant le bon package de la bonne manière. Je n'ai juste aucune idée par où commencer - à part cela, mon système fonctionne complètement normalement et comme prévu.

ÉDITER

Cela m'arrive maintenant sur une machine stable Debian comme décrit ci-dessus. Aucune mise à niveau ou quoi que ce soit cette fois, juste stable.

Oui, un an plus tard. Je ne sais toujours pas quel est le problème.

Voici à quoi cela ressemble maintenant (peu de choses ont changé):

bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
terraria@skaianet:~$ tty
/dev/pts/0
terraria@skaianet:~$ ls -l /dev/pts/0
crw--w---- 1 root root 136, 0 Oct 10 19:21 /dev/pts/0
terraria@skaianet:~$ ls -l /dev/pts/
crw--w---- 1 root root 136, 0 Oct 10 19:21 0
crw--w---- 1 root root 136, 2 Sep 22 17:47 2
crw--w---- 1 root root 136, 3 Sep 26 19:30 3
c--------- 1 root root   5, 2 Sep  7 10:50 ptmx

Une strace générée comme ceci:

root@skaianet:~$ strace -f -o tracelog su terraria -

..aussi révèle un comportement déroutant. Ces messages sont assez déroutants. Quelques lignes choisies:

readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
#Error code 10? 
15503 open("/dev/tty", O_RDWR|O_NONBLOCK) = -1 ENXIO (No such device or address)
#Yes there is, and I can interact with it normally
15503 ioctl(255, TIOCGPGRP, [32561])    = -1 ENOTTY (Inappropriate ioctl for device)

J'ai lié la sortie complète de cette session strace - tout ce que j'ai fait a été d'exécuter la commande su, puis immédiatement ctrl + d hors du terminal.

• su - usernameest interprété par votre sucomme signifiant «exécuter le shell du nom d' utilisateur comme un shell de connexion interactif»
• su username -est interprété par votre sucomme signifiant "exécutez la commande non interactive suivante ( -) en tant que nom d' utilisateur "
• ce dernier n'a fonctionné que parce que:
  • vos supasses à la fin des arguments shpour l'analyse
  • shprend le -sens de « courir comme un shell de connexion (lecture /etc/profile, ...) »

Mais ce qui vous intéresse vraiment, c'est: pourquoi non interactif ? Le partage du terminal de contrôle entre le parent privilégié et l'enfant non privilégié vous rend vulnérable à "l' escalade des privilèges de repoussage ATS ", alias le TIOCSTIbogue, donc à moins que vous n'en ayez vraiment besoin, il s'en su détache . Lorsque vous avez utilisé le su username -formulaire, su vous avez déduit que vous n'aviez pas besoin d'un terminal de contrôle .

Seuls les processus avec un terminal de contrôle peuvent avoir des chefs de session qui manipulent les groupes de processus (font le contrôle des tâches); la trace que vous avez donnée bashdétecte qu'il ne peut pas s'agir d'un chef de session.

Vous mentionnez:

Là où cela devient plus étrange, c'est que les deux formulaires fonctionnent bien sur Ubuntu et CentOS 6, mais sur Debian vanille, seul le premier formulaire fonctionne sans erreur.

Variantes Ignorant les aiment suxet sudo, il y a au moins trois ^[1] versions de suLinux: coreutils, util-linuxet à shadow-utilspartir de laquelle Debian de VIENT. La page de manuel de ce dernier souligne:

Cette version de su possède de nombreuses options de compilation, dont certaines seulement peuvent être utilisées sur un site particulier.

et Debian est livré avec le drapeau old_debian_behavior; d'autres versions peuvent avoir des options de compilation / d'exécution similaires. Une autre raison de la variabilité pourrait être qu'il y a eu un débat ^[2] sur la question de savoir s'il sune devrait jamais être utilisé pour supprimer des privilèges de cette façon et si le TIOCSTIbogue est donc un bogue du tout (Redhat l'a fermé à l' origine "WONTFIX" ).

[1]: Modifier: ajoutez SimplePAMAppset hardened-shadowà cela.

[2]: Solar Designer y a quelques (anciennes) opinions qui, je pense, valent la peine d'être lues.

Je vérifierais la propriété et les autorisations sur / dev / pts * ou pour une nouvelle configuration pour udev liée aux périphériques / dev / pts, qui n'a pas été remplacée pendant le processus de mise à niveau.

Vous pouvez également essayer de savoir quel syscal génère l'erreur en exécutant en tant que root:

strace -f su - username 2>stderr.log