J'avais l'habitude de travailler avec des modèles Ubuntu 10.04 sur de nombreux serveurs. Depuis le passage à 12.04, j'ai des problèmes que j'ai maintenant isolés.
Le périphérique / dev / urandom n'est accessible qu'à root.
Cela a provoqué l'échec des moteurs SSL, au moins en PHP, par exemple file_get_contents (https: // ...
Il a également brisé la mine rouge.
Après un chmod 644, cela fonctionne bien, mais cela ne reste pas au redémarrage.
Donc ma question.
Pourquoi est-ce? Je ne vois aucun risque pour la sécurité parce que ... je veux dire ... tu veux voler des données aléatoires?
Comment puis-je le "réparer"? Les serveurs sont isolés et utilisés par une seule application, c'est pourquoi j'utilise openvz. Je pense à quelque chose comme un script de niveau d'exécution ou plus ... mais comment le faire efficacement? Maby avec dpkg ou apt?
Il en va de même pour vor / dev / shm. dans ce cas, je comprends parfaitement pourquoi ce n'est pas accessible, mais je suppose que je peux le "réparer" de la même manière pour corriger / dev / urandom
la source
ls -l /dev/urandommontre- t -on avant de modifier les autorisations? Avez-vous personnalisé des fichiers/etc/udev/rules.dou/lib/udev/rules.d?root@idle:~# ls -l /dev/urandom crw------- 1 root root 1, 9 May 22 14:15 /dev/urandom- Je n'ai rien défini, c'est un serveur vierge, même la mise à jour apt-get n'a pas encore eu lieu.0644. La question est - pourquoi pas?!Réponses:
Avec une lecture excessive d'udev, vous pouvez vider le pool aléatoire, résultant en des nombres aléatoires prévisibles. C'est probablement la raison pour laquelle / dev / urandom n'est pas disponible pour tout le monde.(supprimé car Graeme Donaldson a raison)Dans le cas où vous souhaitez toujours modifier l'autorisation, examinez les règles udev responsables de la définition des modes sur / dev / urandom, au lieu de gâcher vos scripts d'initialisation.
Sous Debian, il est facile de trouver la règle coupable:
Dans votre cas, MODE n'est certainement pas 0666.
Modifiez-le selon les règles de configuration udev, si vous le souhaitez.
Remarque: http://lists.centos.org/pipermail/centos/2009-July/079134.html peut aider à changer udev.
Vous aurez essentiellement besoin de créer une règle qui ressemble au résultat grep, sauf qu'il a un mode correct défini, et l'ajouter en tant que fichier de règles dans /etc/udev/rules.d/ (attention aux différences possibles dans Ubuntu et Debian !)
la source
/dev/randomse bloque lorsque l'estimation d'entropie est faible, tout en/dev/urandomcontinuant à produire des nombres pseudo-aléatoires même lorsque l'estimation d'entropie est faible. Cela dit, le concept entier du pool d'entropie "d'une manière ou d'une autre aléatoire" est trompeur et dénué de sens .Quant à la façon dont vous pouvez le réparer, un pansement temporaire serait de simplement
la source
/etc/rc.localfichier. Dans mon cas (Ubuntu 16.04), le fichier s'est terminé avec la sortie 0, donc si vous ajoutez simplement une ligne, cela ne fonctionnerait en effet pas.en fait, le modèle ubuntu 12.04 openvz est maintenant public et ils ont fixé les autorisations aussi bien sur l'uraondm que sur le périphérique shm
la source
Le problème que udevtrigger n'a pas été démarré. Essayez de redémarrer avec
/etc/init.d/udevtrigger restart... et si cela résout le problème comme pour moi ... alors changez le fichier /etc/init/udevtrigger.conf:la source
Dans RHEL: ajoutez des règles de sécurité avec des remplacements d'autorisations dans /etc/security/console.perms.d/
doit être similaire dans ubuntu
la source