PING icmp open socket: opération non autorisée dans vserver

14

J'exécute un environnement vserver avec plusieurs machines virtuelles. Une seule machine virtuelle a le problème suivant:

$ 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

Notez que sur la machine hôte ainsi que sur tous les autres hôtes VM, Ping fonctionne correctement.

Quelqu'un a-t-il une idée pour m'aider, s'il vous plaît?

permissions virtual-machines ping

— rexkogitans
source

Le /bin/pingset-uid est -il sur les autres machines? TCP / IP est-il correctement configuré sur cette machine virtuelle? Est-ce que d'autres choses fonctionnent comme DNS, traceroute, HTTP?

— David Schwartz

2

Avez-vous essayé de réinstaller iputils-ping?

— Nabil Bourenane

Une autre information peut être utile: il s'agit d'une machine très productive exécutant Apache avec environ 5 à 7 accès par seconde - donc aucune idée de modifier la configuration du réseau. Il est passé à un nouveau matériel la nuit dernière, et depuis lors, Munin montre que Ping ne fonctionne pas.

— rexkogitans

12

Version TL; DR: réinstaller iputils-ping

J'ai vu en ligne où il a été suggéré d'utiliser

chmod u+s $( which ping );

Cependant, cela permettra à l'utilisateur de modifier la précharge et l'inondation. Ce qui pourrait entraîner un UTILISATEUR en mesure de dénier le service soit votre machine locale ou une autre machine ou votre réseau.

J'ai essayé ce que @ nabil-bourenane a suggéré , en réinstallant iputils-pingce qui a résolu le problème pour moi et n'a pas le bit SUID défini.

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

Si le bit SUID est défini, il ressemblera à

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

— Linx
source

Si vous êtes déjà root, les binaires racine SUID ne changeront pas grand-chose.

— Falcon Momot

@FalconMomot, j'ai ajouté la solution.

— rexkogitans

La réinstallation d'iputils (même version avant / après) a fonctionné pour moi sur centos7. Avant, getcap / bin / ping ne montrait aucune capacité définie. Après réinstallation, de getcap /bin/pingretour: /bin/ping = cap_net_admin,cap_net_raw+p. Maintenant, la question est: pourquoi il a perdu ses capacités. rpm --verify iputilsa montré que ping, arping et clockdiff ont tous montré que les paramètres de plafond avaient changé (avant la réinstallation).

— Juan

Dans mon cas, il peut avoir perdu des capacités de fichier après une restauration à partir d'une image de vidage. Voir aussi unix.com/unix-for-advanced-and-expert-users/… . Dans ce cas, ils ont utilisé du goudron. Dans mon cas, j'espérais que le vidage / restauration préservait tous ces attributs de fichier (attrs, capacités, acls, etc.). Je suis surpris que ce ne soit pas le cas, je vais donc devoir voir si je peux le reproduire (et ensuite peut-être enregistrer un bug).

— Juan

1

La solution consiste à définir les capacités du système Linux pour autoriser le socket brut sur la machine hôte.

Puisqu'il s'agit d'un problème très spécifique au serveur virtuel, la solution consiste à créer un fichier à ligne unique nommé /etc/vservers/VMNAME/bcapabilities:

NET_RAW

et redémarrez VM.

— rexkogitans
source

1

"Et comment faites-vous cela?" serait utile comme réponse complète.

— ILMostro_7

Après 4 ans, j'ai changé la réponse acceptée pour la mienne, car elle répond vraiment à la question. Il s'agit d'un problème de serveur virtuel et n'a rien à voir avec le mode de fichier de l'exécutable ping.

— rexkogitans

1

Désolé, je ne peux pas commenter. Ce problème m'a frappé après avoir extrait une archive d'un système qui fonctionne sur une installation minimale.

Toutes les réponses ci-dessus fonctionnent. Mais celui proposé par @Nabil Bourenane et @Linx est préféré pour la sécurité. Pour répondre au commentaire de @ rexkogitans, je cite ici 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

qui dit essentiellement lors de la configuration de iputils-ping, essayez d'abord setcap puis si cela échoue, utilisez chmod u + s. C'est pourquoi la réinstallation d'iputils-ping fonctionne.

— rlf
source

1

Donc cela fonctionnera: setcap cap_net_raw + ep / bin / ping

— rlf

Ce n'était pas mon commentaire, mais ma réponse à ma propre question. Le problème ne peut pas être résolu depuis l'intérieur du conteneur, donc quoi que fasse le crochet de post-installation est inutile.

— rexkogitans

En effet, setcap cap_net_raw+p $(which ping)comme root le corrige. Il y a une explication approfondie sur ce billet de blog: Linux Capabilities and Ping

— mivk