PING icmp open socket: operación no permitida en vserver

14

Estoy ejecutando un entorno vserver con varias máquinas virtuales. Una sola VM tiene el siguiente problema:

$ ping 8.8.8.8
ping: icmp open socket: Operation not permitted

$ ls -l $(which ping)
-rwsr-xr-x 1 root root 30736 2007-01-31 00:10 /bin/ping

$ whoami
root

$ mount
/dev/hdv1 on / type ufs (defaults)
none on /proc type proc (0)
none on /tmp type tmpfs (size=16m,mode=1777)
none on /dev/pts type devpts (gid=5,mode=620)

$ uname -a
Linux v-web1 2.6.27.55-vs2.3.0.36.9 #1 SMP Tue Apr 28 11:35:00 CEST 2015 i686 GNU/Linux

Tenga en cuenta que en la máquina host, así como en todos los demás hosts VM allí, Ping funciona bien.

¿Alguien tiene alguna idea para ayudarme, por favor?

rexkogitans
fuente
¿Está /bin/pingset-uid en las otras máquinas? ¿TCP / IP está configurado correctamente en esta VM? ¿Otras cosas funcionan como DNS, traceroute, HTTP?
David Schwartz
2
¿Intentaste reinstalar iputils-ping?
Nabil Bourenane
Otra información puede ser útil: esta es una máquina altamente productiva que ejecuta Apache con aproximadamente 5 a 7 accesos por segundo, por lo que no tiene idea de modificar la configuración de la red. Anoche se mudó a un nuevo hardware, y desde entonces, Munin muestra que Ping no está funcionando.
rexkogitans

Respuestas:

12

TL; versión DR: reinstalar iputils-ping

He visto en línea dónde se ha sugerido usar

chmod u+s $( which ping );

Sin embargo, esto permitirá al usuario cambiar la precarga y la inundación. Lo que podría resultar en que un USUARIO pueda denegar el servicio, ya sea su máquina local u otra máquina o su red.

Intenté lo que sugirió @ nabil-bourenane , reinstalando lo iputils-pingque resolvió el problema para mí y no tiene el bit SUID establecido.

username@server:~$ ls -l $( which ping );
-rwxr-xr-x 1 root root 44104 Nov  8  2014 /bin/ping

Si el bit SUID está configurado, se verá como

username@server:~$ ls -l $( which ping );
-rwsr-xr-x 1 root root 44104 Nov  8  2014 /bin/ping
Linx
fuente
Si ya es root, los binarios de raíz SUID no cambiarán mucho.
Falcon Momot
@ FalconMomot, agregué la solución.
rexkogitans
1

La solución es configurar las capacidades del sistema Linux para permitir un socket sin procesar en la máquina host.

Dado que este es un problema muy específico del servidor v, la solución es crear un archivo de una sola línea llamado /etc/vservers/VMNAME/bcapabilities:

NET_RAW

y reiniciar VM.

rexkogitans
fuente
1
"¿Y cómo logras esto?" Sería útil como respuesta completa.
ILMostro_7
Después de 4 años, cambié la respuesta aceptada a la mía, porque REALMENTE RESPONDE LA PREGUNTA. Este es un problema del servidor v y no tiene nada que ver con el modo de archivo del ejecutable ping.
rexkogitans
1

Lo siento, no puedo comentar. Este problema me golpeó después de extraer un archivo de un sistema en funcionamiento en una instalación mínima.

Todas las respuestas anteriores funcionan. Pero la propuesta por @Nabil Bourenane y @Linx se prefiere por seguridad. Para responder al comentario de @ rexkogitans, aquí cito de iputils-ping.postinst (/ var / lib / dpkg / info / ...)

if command -v setcap > /dev/null; then
    if setcap cap_net_raw+ep /bin/ping; then
        chmod u-s /bin/ping
    else
        echo "Setcap failed on /bin/ping, falling back to setuid" >&2
        chmod u+s /bin/ping
    fi
else
    echo "Setcap is not installed, falling back to setuid" >&2
    chmod u+s /bin/ping
fi

que básicamente dice que al configurar iputils-ping, primero intente setcap y luego, si eso falla, use chmod u + s. Es por eso que reinstalar iputils-ping funciona.

rlf
fuente
1
Entonces esto funcionará: setcap cap_net_raw + ep / bin / ping
rlf
No fue mi comentario, sino mi respuesta a mi propia pregunta. El problema no se puede resolver desde el contenedor, por lo que lo que sea que haga el gancho posterior a la instalación no tiene sentido.
rexkogitans
De hecho, setcap cap_net_raw+p $(which ping)como root lo arregla. Hay una explicación detallada en esta publicación de blog: Capacidades de Linux y Ping
mivk