"No se puede establecer el grupo de proceso de terminal" durante su para otro usuario como shell de inicio de sesión

Nota: Lea la información actualizada que comienza con "EDITAR" cerca del punto medio de esta publicación: el entorno y los antecedentes de este problema han cambiado

Aquí tengo una instalación estándar de Debian 6.0 que decidí cambiar a los repositorios de Debian Testing. Hice esto intercambiando las referencias a los repositorios de Squeeze en mi sources.list para usar los repositorios de prueba.

Después de la instalación del paquete y un reinicio, aparece el siguiente error cuando intento su - a otro usuario:

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

Si omito el -, esto no ocurre.

Tenga en cuenta que los usuarios pueden convertirse en root correctamente, esto solo parece suceder cuando se cambia de root a otra persona y se usa - para obtener el entorno de ese usuario.

Google es en su mayoría inútil aquí. Las únicas cosas que puedo encontrar son referencias de 2011 con respecto al suxpaquete, que parecen haberse solucionado mientras tanto.

Esto se ve y huele mucho a un error de actualización, solucionable ajustando el paquete correcto de la manera correcta. Simplemente no tengo idea por dónde empezar, aparte de esto, mi sistema funciona de manera completamente normal y como se esperaba.

EDITAR

Esto me está sucediendo ahora en una máquina estable de Debian como se describió anteriormente. Sin actualización ni nada esta vez, solo estable.

Sí, un año después. Todavía no tengo idea de qué diablos es el problema.

Esto es lo que parece ahora (no ha cambiado mucho):

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

Un estrato generado así:

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

..también aparece un comportamiento confuso. Estos mensajes son bastante confusos. Algunas líneas elegidas:

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)

He vinculado el resultado completo de esta sesión de strace : todo lo que hice fue ejecutar el comando su, e inmediatamente ctrl + d fuera del terminal.

• su - usernamees interpretado por usted sucomo "ejecutar el shell del nombre de usuario como un shell de inicio de sesión interactivo"
• su username -es interpretado por usted sucomo "ejecutar el siguiente comando no interactivo ( -) como nombre de usuario "
• este último solo funcionó en absoluto porque:
  • sus supases argumentos finales shpara analizar
  • shtoma -para significar "ejecutar como un shell de inicio de sesión (leer /etc/profile, ...)"

Pero lo que realmente le interesa es: ¿por qué no es interactivo ? Compartir el terminal de control entre el padre privilegiado y el niño no privilegiado lo deja vulnerable a la " escalada de privilegios de retroceso TTY ", también conocido como el TIOCSTIerror, por lo que, a menos que realmente lo necesite, se su desconecta de él . Cuando usó el su username -formulario, su infirió que no necesitaba un terminal de control .

Solo los procesos con un terminal de control pueden tener líderes de sesión que manipulen los grupos de procesos (hacer el control del trabajo); el rastro que diste es bashdetectar que no puede ser un líder de sesión.

Mencionas:

Lo que se vuelve extraño es que ambas formas funcionan bien en Ubuntu y CentOS 6, sin embargo, en Debian vanilla, solo la primera forma funciona sin errores.

Haciendo caso omiso de las variantes gusta suxy sudo, existen al menos tres ^[1] versiones de suLinux: coreutils, util-linuxy shadow-utilsde la que viene de Debian. La página de manual de este último señala:

Esta versión de su tiene muchas opciones de compilación, solo algunas de las cuales pueden estar en uso en un sitio en particular.

y Debian viene con la bandera old_debian_behavior; otras versiones pueden tener opciones similares de tiempo de compilación / tiempo de ejecución. Otra razón para la variabilidad podría ser que hubo un debate ^[2] sobre si sualguna vez se debe usar para eliminar privilegios de esta manera y si el TIOCSTIerror es por lo tanto un error (Redhat originalmente lo cerró "WONTFIX" ).

[1]: Editar: agregar SimplePAMAppsy hardened-shadowa eso.

[2]: Solar Designer tiene algunas opiniones (antiguas) que creo que valen la pena leer.

Verificaría la propiedad y los permisos en / dev / pts * o para una nueva configuración para udev relacionada con dispositivos / dev / pts, que no fue reemplazada durante el proceso de actualización.

También puede intentar averiguar qué syscal está generando el error ejecutándose como root:

strace -f su - username 2>stderr.log