Je suis une application client / serveur sur Red Hat Enterprise à l'aide de ZMQ pour le passage de message. La prise IPC utilisée pour associer un client avec le serveur est implémentée à l'aide d'une prise de domaine UNIX.
Si l'utilisateur A démarre le processus de serveur, il semble que seuls les clients commencent par l'utilisateur A peuvent se connecter et communiquer sur cette prise. Notre projet nécessite que les clients puissent être exécutés par différents utilisateurs. Il s'agit donc d'un point de collage majeur.
La prise est située au / TMP / IPC_ASSOC avec des autorisations de 755 par défaut. est ce comportement typique des prises de domaine UNIX? Quelqu'un a-t-il compris comment travailler autour d'elle? chmod 777 ne résout pas le problème. Chown UserB permet à l'utilisateur B d'accéder à la prise, mais l'utilisateur A perd ensuite l'accès. On ne peut même pas accéder à la prise. Il n'y a pas de ACL ou SELINUX à utiliser sur la machine.
4 Réponses :
Avez-vous essayé d'ajouter Usera et UserB dans un groupe d'utilisateurs communs?
Est un lien symbolique vers un autre fichier avec des autorisations différentes?
Non, si vous exécutez ls -l sur la prise, il imprime "SRWXR-XR-X ... IPC_ASSOC"
Cela semble montrer que la prise est uniquement R / W / X pour le propriétaire, pas le groupe. Lorsque vous créez le fichier dans le processus de serveur, il utilisera l'umask pour le processus 755, change de manière programmée sur le masque ou chmod le fichier à 770.
Avec une assistance de la liste de diffusion ZMQ, j'ai effectué un travail. C'est moche, mais semble travailler systématiquement.
Je devais faire un sous-répertoire sous / TMP et Je ne sais pas pourquoi le socket de domaine UNIX se comporte de cette façon, mais c'est sûr que c'est ennuyeux. chmod 777 . Le serveur crée maintenant la prise dans ce nouveau dossier. Il est également programmatiquement chmod 777 la prise. Maintenant, tant que le serveur est exécuté en tant que root, tout utilisateur peut exécuter un client et parler au serveur.
Pourquoi 777 fonctionnent-il alors que 770 ne le fait pas? Je suis perplexe, j'ai mis les deux utilisateurs sous le même groupe et non ...
Cela vous permet d'ouvrir une attaque dans laquelle un utilisateur non provisuré peut créer une prise du même nom et recevoir toutes les données destinées à vous. mieux rendre le répertoire ne pas avoir d'autorisations d'écriture et trouver une autre façon de faire la prise 777
chmod (s.sun_path, 0777); strong> après avoir écouté la prise. domain = AF_UNIX;
name = servname;
port = -1;
n = MakeLocalSocket(s);
if (n == 0) {
fatal("can't create socket");
}
unlink(s.sun_path);
if (bind(fd, & s, n) < 0) {
fatal("can't bind socket");
}
if (listen(fd, 5) != 0) {
fatal("can't listen to socket");
}
/* UNIX domain sockets need to be mode 777 on 4.3 */
chmod(s.sun_path, 0777);
Pourquoi 777 fonctionnent-il alors que 770 ne le fait pas? Je suis perplexe, j'ai mis les deux utilisateurs sous le même groupe et non ...
Pas certain. Cependant, selon man7.org/linux/man-pages/man7/ Unix.7.html "POSIX ne fait aucune déclaration sur l'effet des autorisations sur un fichier de socket et sur certains systèmes (par exemple, les BSD plus anciennes), les autorisations de socket sont ignorées. Les programmes portables ne doivent pas compter sur cette fonctionnalité pour la sécurité. "
En fait, j'ai résolu le problème: l'utilisateur que j'ai ajouté au groupe devait se connecter à ce changement pour prendre effet! Mais merci pour votre commentaire
(Offtopic NB: Aimez votre photo de profil, c'est de mon film préféré: D)
altérer temporairement l'umask: Bien sûr, c'est une mauvaise idée si vous utilisez des threads.