je cherche a implementer un systeme de communication entre divers
processus de meme uid. quelque chose du genre:
send(pid_t pid_dest, char *message);
ceci sous la forme d'une bibliotheque statique qui devra - idealement -
etre portable sous tout UNIX recent.
j'ai pense aux files d'attentes de messages (message queues).
je creerais une file unique pour tous les processus, et ils recevront ou
emettront leurs messages avec le message type == a leur pid.
le probleme de cette methode, c est que l'id de la file etant connue de
tous (un define dans le code), n'importe quel utilisateur peut faire un
"msgrcv" et lire des messages qui ne lui sont pas adresses.
j'ai vu qu'il y avait un systeme de permissions avec les ipc, alors
j'hesite entre ces deux solutions:
- soit creer une file de message par processus
par exemple le processus de pid 421 creerait sa file "de reception",
mais le probleme c est que ca "reserverait" de tres nombreux identifiant
de queue et ca pourrait etre genant sur le systeme (peut etre) et
consommer trop de ressources (peut etre).
- soit creer une file unique avec pour uid root, avec des permissions
402 qui change d'uid provisoirement quand un processus doit recevoir un
message qui lui est destine
auriez vous des suggestions ou des avis sur ces solutions? voir meme des
idees autres si ca n'est pas faisable.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
DINH Viêt Hoà
j'ai pense aux files d'attentes de messages (message queues). je creerais une file unique pour tous les processus, et ils recevront ou emettront leurs messages avec le message type == a leur pid. le probleme de cette methode, c est que l'id de la file etant connue de tous (un define dans le code), n'importe quel utilisateur peut faire un "msgrcv" et lire des messages qui ne lui sont pas adresses.
comment sais-tu que le prochain message qui va être reçu par msgrcv() va être destiné à un processus donné ? Les permissions IPC sont-elles des permissions utilisateurs ou des permissions processus ? Comment les permissions entre les processus d'un même utilisateur sont gérées ?
j'ai vu qu'il y avait un systeme de permissions avec les ipc, alors j'hesite entre ces deux solutions:
- soit creer une file de message par processus
Je ne vois pas d'inconvénient à créer une resource par processus. Si ce n'est qu'il faut faire attention à libérer la resource créée, surtout s'il s'agit d'IPC System V.
Si les IPC system V te limitent le nombre de resources créées, tu peux éventuellement passer par un processus central qui va se charger de créer les cannaux entre processus.
-- DINH V. Hoa,
"Ma tuxitude me beastifie" -- sunZ
j'ai pense aux files d'attentes de messages (message queues).
je creerais une file unique pour tous les processus, et ils recevront ou
emettront leurs messages avec le message type == a leur pid.
le probleme de cette methode, c est que l'id de la file etant connue de
tous (un define dans le code), n'importe quel utilisateur peut faire un
"msgrcv" et lire des messages qui ne lui sont pas adresses.
comment sais-tu que le prochain message qui va être reçu par msgrcv()
va être destiné à un processus donné ?
Les permissions IPC sont-elles des permissions utilisateurs ou
des permissions processus ?
Comment les permissions entre les processus d'un même utilisateur
sont gérées ?
j'ai vu qu'il y avait un systeme de permissions avec les ipc, alors
j'hesite entre ces deux solutions:
- soit creer une file de message par processus
Je ne vois pas d'inconvénient à créer une resource par processus.
Si ce n'est qu'il faut faire attention à libérer la resource créée,
surtout s'il s'agit d'IPC System V.
Si les IPC system V te limitent le nombre de resources créées, tu
peux éventuellement passer par un processus central qui va se charger
de créer les cannaux entre processus.
j'ai pense aux files d'attentes de messages (message queues). je creerais une file unique pour tous les processus, et ils recevront ou emettront leurs messages avec le message type == a leur pid. le probleme de cette methode, c est que l'id de la file etant connue de tous (un define dans le code), n'importe quel utilisateur peut faire un "msgrcv" et lire des messages qui ne lui sont pas adresses.
comment sais-tu que le prochain message qui va être reçu par msgrcv() va être destiné à un processus donné ? Les permissions IPC sont-elles des permissions utilisateurs ou des permissions processus ? Comment les permissions entre les processus d'un même utilisateur sont gérées ?
j'ai vu qu'il y avait un systeme de permissions avec les ipc, alors j'hesite entre ces deux solutions:
- soit creer une file de message par processus
Je ne vois pas d'inconvénient à créer une resource par processus. Si ce n'est qu'il faut faire attention à libérer la resource créée, surtout s'il s'agit d'IPC System V.
Si les IPC system V te limitent le nombre de resources créées, tu peux éventuellement passer par un processus central qui va se charger de créer les cannaux entre processus.
-- DINH V. Hoa,
"Ma tuxitude me beastifie" -- sunZ
Guillaume Desticourt
DINH Viêt Hoà wrote:
j'ai pense aux files d'attentes de messages (message queues). je creerais une file unique pour tous les processus, et ils recevront ou emettront leurs messages avec le message type == a leur pid. le probleme de cette methode, c est que l'id de la file etant connue de tous (un define dans le code), n'importe quel utilisateur peut faire un "msgrcv" et lire des messages qui ne lui sont pas adresses.
comment sais-tu que le prochain message qui va être reçu par msgrcv() va être destiné à un processus donné ?
et bien j'etais parti dans l'idee que lors de l initialisation de ma bibliotheque, je creerais une thread qui bouclerait sur un msgrcv(msqid, &msg, msgsize, getpid(), flags) bloquant. le probleme a lieu si un utilisateur malveillant se cree un programme faisant un msgrcv(msqid, &msg, msgsize, le_pid_d_un_autre_processus, flags);
Les permissions IPC sont-elles des permissions utilisateurs ou des permissions processus ?
heu.. je ne suis pas sur de comprendre ta question... ca revient un peu au meme dans la mesure ou l'uid d'un processus est - en general - celui de l'utilisateur qui l'a lance.
Comment les permissions entre les processus d'un même utilisateur sont gérées ?
a nouveau je ne vois pas trop ce que tu veux dire. tout processus a droit de faire un msgsnd sur ma file de message. et tout les processus ont le droit de faire un msgrcv (sinon difficile de recevoir le message). et c'est bien la le probleme.
j'ai vu qu'il y avait un systeme de permissions avec les ipc, alors j'hesite entre ces deux solutions:
- soit creer une file de message par processus
Je ne vois pas d'inconvénient à créer une resource par processus. Si ce n'est qu'il faut faire attention à libérer la resource créée, surtout s'il s'agit d'IPC System V.
je me demandais simplement si creer 10000 files de messages - si j'ai par exemple 10000 processus utilisant ma lib tournant simultanement - n'allait pas poser des problemes a mon systeme.
Si les IPC system V te limitent le nombre de resources créées, tu peux éventuellement passer par un processus central qui va se charger de créer les cannaux entre processus.
hum... tu veux dire un demon sur lequel tous les processus feraient leur msgsnd. mais que veux tu dire par creer un canal?
par exemple si le processus de pid 32 envoit un message au demon, qui doit etre livre au processus de pid 59, comment mon demon pourrait il creer un canal de communication entre lui meme et le processus 59 puisqu'il faut une clef commune?
un ami me proposait de creer un fichier /var/malib/59 qui contiendrait la clef ipc du processus 59, mais je me demande a quel point cela serait lent de passer par le systeme de fichier...
en esperant avoir ete clair,
-- Guillaume Desticourt
DINH Viêt Hoà wrote:
j'ai pense aux files d'attentes de messages (message queues).
je creerais une file unique pour tous les processus, et ils recevront ou
emettront leurs messages avec le message type == a leur pid.
le probleme de cette methode, c est que l'id de la file etant connue de
tous (un define dans le code), n'importe quel utilisateur peut faire un
"msgrcv" et lire des messages qui ne lui sont pas adresses.
comment sais-tu que le prochain message qui va être reçu par msgrcv()
va être destiné à un processus donné ?
et bien j'etais parti dans l'idee que lors de l initialisation de ma
bibliotheque, je creerais une thread qui bouclerait sur un msgrcv(msqid,
&msg, msgsize, getpid(), flags) bloquant.
le probleme a lieu si un utilisateur malveillant se cree un programme
faisant un msgrcv(msqid, &msg, msgsize, le_pid_d_un_autre_processus, flags);
Les permissions IPC sont-elles des permissions utilisateurs ou
des permissions processus ?
heu.. je ne suis pas sur de comprendre ta question... ca revient un peu
au meme dans la mesure ou l'uid d'un processus est - en general -
celui de l'utilisateur qui l'a lance.
Comment les permissions entre les processus d'un même utilisateur
sont gérées ?
a nouveau je ne vois pas trop ce que tu veux dire. tout processus a
droit de faire un msgsnd sur ma file de message. et tout les processus
ont le droit de faire un msgrcv (sinon difficile de recevoir le
message). et c'est bien la le probleme.
j'ai vu qu'il y avait un systeme de permissions avec les ipc, alors
j'hesite entre ces deux solutions:
- soit creer une file de message par processus
Je ne vois pas d'inconvénient à créer une resource par processus.
Si ce n'est qu'il faut faire attention à libérer la resource créée,
surtout s'il s'agit d'IPC System V.
je me demandais simplement si creer 10000 files de messages - si j'ai
par exemple 10000 processus utilisant ma lib tournant simultanement -
n'allait pas poser des problemes a mon systeme.
Si les IPC system V te limitent le nombre de resources créées, tu
peux éventuellement passer par un processus central qui va se charger
de créer les cannaux entre processus.
hum... tu veux dire un demon sur lequel tous les processus feraient leur
msgsnd. mais que veux tu dire par creer un canal?
par exemple si le processus de pid 32 envoit un message au demon, qui
doit etre livre au processus de pid 59, comment mon demon pourrait il
creer un canal de communication entre lui meme et le processus 59
puisqu'il faut une clef commune?
un ami me proposait de creer un fichier /var/malib/59 qui contiendrait
la clef ipc du processus 59, mais je me demande a quel point cela serait
lent de passer par le systeme de fichier...
j'ai pense aux files d'attentes de messages (message queues). je creerais une file unique pour tous les processus, et ils recevront ou emettront leurs messages avec le message type == a leur pid. le probleme de cette methode, c est que l'id de la file etant connue de tous (un define dans le code), n'importe quel utilisateur peut faire un "msgrcv" et lire des messages qui ne lui sont pas adresses.
comment sais-tu que le prochain message qui va être reçu par msgrcv() va être destiné à un processus donné ?
et bien j'etais parti dans l'idee que lors de l initialisation de ma bibliotheque, je creerais une thread qui bouclerait sur un msgrcv(msqid, &msg, msgsize, getpid(), flags) bloquant. le probleme a lieu si un utilisateur malveillant se cree un programme faisant un msgrcv(msqid, &msg, msgsize, le_pid_d_un_autre_processus, flags);
Les permissions IPC sont-elles des permissions utilisateurs ou des permissions processus ?
heu.. je ne suis pas sur de comprendre ta question... ca revient un peu au meme dans la mesure ou l'uid d'un processus est - en general - celui de l'utilisateur qui l'a lance.
Comment les permissions entre les processus d'un même utilisateur sont gérées ?
a nouveau je ne vois pas trop ce que tu veux dire. tout processus a droit de faire un msgsnd sur ma file de message. et tout les processus ont le droit de faire un msgrcv (sinon difficile de recevoir le message). et c'est bien la le probleme.
j'ai vu qu'il y avait un systeme de permissions avec les ipc, alors j'hesite entre ces deux solutions:
- soit creer une file de message par processus
Je ne vois pas d'inconvénient à créer une resource par processus. Si ce n'est qu'il faut faire attention à libérer la resource créée, surtout s'il s'agit d'IPC System V.
je me demandais simplement si creer 10000 files de messages - si j'ai par exemple 10000 processus utilisant ma lib tournant simultanement - n'allait pas poser des problemes a mon systeme.
Si les IPC system V te limitent le nombre de resources créées, tu peux éventuellement passer par un processus central qui va se charger de créer les cannaux entre processus.
hum... tu veux dire un demon sur lequel tous les processus feraient leur msgsnd. mais que veux tu dire par creer un canal?
par exemple si le processus de pid 32 envoit un message au demon, qui doit etre livre au processus de pid 59, comment mon demon pourrait il creer un canal de communication entre lui meme et le processus 59 puisqu'il faut une clef commune?
un ami me proposait de creer un fichier /var/malib/59 qui contiendrait la clef ipc du processus 59, mais je me demande a quel point cela serait lent de passer par le systeme de fichier...
en esperant avoir ete clair,
-- Guillaume Desticourt
DINH Viêt Hoà
a nouveau je ne vois pas trop ce que tu veux dire. tout processus a droit de faire un msgsnd sur ma file de message. et tout les processus ont le droit de faire un msgrcv (sinon difficile de recevoir le message). et c'est bien la le probleme.
Par "permissions", je veux dire qu'un processus du même utilisateur peut venir perturber le fonctionnement de tes communications.
j'ai vu qu'il y avait un systeme de permissions avec les ipc, alors j'hesite entre ces deux solutions:
- soit creer une file de message par processus
Je ne vois pas d'inconvénient à créer une resource par processus. Si ce n'est qu'il faut faire attention à libérer la resource créée, surtout s'il s'agit d'IPC System V.
je me demandais simplement si creer 10000 files de messages - si j'ai par exemple 10000 processus utilisant ma lib tournant simultanement - n'allait pas poser des problemes a mon systeme.
Si les IPC system V te limitent le nombre de resources créées, tu peux éventuellement passer par un processus central qui va se charger de créer les cannaux entre processus.
hum... tu veux dire un demon sur lequel tous les processus feraient leur msgsnd. mais que veux tu dire par creer un canal?
par exemple si le processus de pid 32 envoit un message au demon, qui doit etre livre au processus de pid 59, comment mon demon pourrait il creer un canal de communication entre lui meme et le processus 59 puisqu'il faut une clef commune?
Le démon va écouter sur un socket unix. Les processus vont communiquer avec le démon par ce socket unix. Lorsque tu vas créer tu vas initialiser ta connexion entre tes 2 processus, tu envoies à chacun en réponse l'identifiant commun à la connexion, par exemple le nom pipe nommé qui sera créé.
Ils pourront ainsi communiquer par ce pipe nommé.
Tu peux aussi remplacer ce pipe nommé par un descripteur de canal de message IPC system V.
un ami me proposait de creer un fichier /var/malib/59 qui contiendrait la clef ipc du processus 59, mais je me demande a quel point cela serait lent de passer par le systeme de fichier...
mouais, ça me paraît du même tonneau que les IPC system V.
Le problème avec le fait de passer par le système de fichier ou bien par les IPC system V, c'est qu'il faut détruire les ressources inutilisées.
Ceci dit, n'es-tu pas en train de réinventer Corba ?
-- DINH V. Hoa,
"Ma tuxitude me beastifie" -- sunZ
a nouveau je ne vois pas trop ce que tu veux dire. tout processus a
droit de faire un msgsnd sur ma file de message. et tout les processus
ont le droit de faire un msgrcv (sinon difficile de recevoir le
message). et c'est bien la le probleme.
Par "permissions", je veux dire qu'un processus du même utilisateur peut
venir perturber le fonctionnement de tes communications.
j'ai vu qu'il y avait un systeme de permissions avec les ipc, alors
j'hesite entre ces deux solutions:
- soit creer une file de message par processus
Je ne vois pas d'inconvénient à créer une resource par processus.
Si ce n'est qu'il faut faire attention à libérer la resource créée,
surtout s'il s'agit d'IPC System V.
je me demandais simplement si creer 10000 files de messages - si j'ai
par exemple 10000 processus utilisant ma lib tournant simultanement -
n'allait pas poser des problemes a mon systeme.
Si les IPC system V te limitent le nombre de resources créées, tu
peux éventuellement passer par un processus central qui va se charger
de créer les cannaux entre processus.
hum... tu veux dire un demon sur lequel tous les processus feraient leur
msgsnd. mais que veux tu dire par creer un canal?
par exemple si le processus de pid 32 envoit un message au demon, qui
doit etre livre au processus de pid 59, comment mon demon pourrait il
creer un canal de communication entre lui meme et le processus 59
puisqu'il faut une clef commune?
Le démon va écouter sur un socket unix.
Les processus vont communiquer avec le démon par ce socket unix.
Lorsque tu vas créer tu vas initialiser ta connexion entre tes 2
processus, tu envoies à chacun en réponse l'identifiant commun à la
connexion, par exemple le nom pipe nommé qui sera créé.
Ils pourront ainsi communiquer par ce pipe nommé.
Tu peux aussi remplacer ce pipe nommé par un descripteur de canal de
message IPC system V.
un ami me proposait de creer un fichier /var/malib/59 qui contiendrait
la clef ipc du processus 59, mais je me demande a quel point cela serait
lent de passer par le systeme de fichier...
mouais, ça me paraît du même tonneau que les IPC system V.
Le problème avec le fait de passer par le système de fichier ou bien par
les IPC system V, c'est qu'il faut détruire les ressources inutilisées.
Ceci dit, n'es-tu pas en train de réinventer Corba ?
a nouveau je ne vois pas trop ce que tu veux dire. tout processus a droit de faire un msgsnd sur ma file de message. et tout les processus ont le droit de faire un msgrcv (sinon difficile de recevoir le message). et c'est bien la le probleme.
Par "permissions", je veux dire qu'un processus du même utilisateur peut venir perturber le fonctionnement de tes communications.
j'ai vu qu'il y avait un systeme de permissions avec les ipc, alors j'hesite entre ces deux solutions:
- soit creer une file de message par processus
Je ne vois pas d'inconvénient à créer une resource par processus. Si ce n'est qu'il faut faire attention à libérer la resource créée, surtout s'il s'agit d'IPC System V.
je me demandais simplement si creer 10000 files de messages - si j'ai par exemple 10000 processus utilisant ma lib tournant simultanement - n'allait pas poser des problemes a mon systeme.
Si les IPC system V te limitent le nombre de resources créées, tu peux éventuellement passer par un processus central qui va se charger de créer les cannaux entre processus.
hum... tu veux dire un demon sur lequel tous les processus feraient leur msgsnd. mais que veux tu dire par creer un canal?
par exemple si le processus de pid 32 envoit un message au demon, qui doit etre livre au processus de pid 59, comment mon demon pourrait il creer un canal de communication entre lui meme et le processus 59 puisqu'il faut une clef commune?
Le démon va écouter sur un socket unix. Les processus vont communiquer avec le démon par ce socket unix. Lorsque tu vas créer tu vas initialiser ta connexion entre tes 2 processus, tu envoies à chacun en réponse l'identifiant commun à la connexion, par exemple le nom pipe nommé qui sera créé.
Ils pourront ainsi communiquer par ce pipe nommé.
Tu peux aussi remplacer ce pipe nommé par un descripteur de canal de message IPC system V.
un ami me proposait de creer un fichier /var/malib/59 qui contiendrait la clef ipc du processus 59, mais je me demande a quel point cela serait lent de passer par le systeme de fichier...
mouais, ça me paraît du même tonneau que les IPC system V.
Le problème avec le fait de passer par le système de fichier ou bien par les IPC system V, c'est qu'il faut détruire les ressources inutilisées.
Ceci dit, n'es-tu pas en train de réinventer Corba ?
-- DINH V. Hoa,
"Ma tuxitude me beastifie" -- sunZ
Guillaume Desticourt
DINH Viêt Hoà wrote:
par exemple si le processus de pid 32 envoit un message au demon, qui doit etre livre au processus de pid 59, comment mon demon pourrait il creer un canal de communication entre lui meme et le processus 59 puisqu'il faut une clef commune?
Le démon va écouter sur un socket unix. Les processus vont communiquer avec le démon par ce socket unix. Lorsque tu vas créer tu vas initialiser ta connexion entre tes 2 processus, tu envoies à chacun en réponse l'identifiant commun à la connexion, par exemple le nom pipe nommé qui sera créé.
Ils pourront ainsi communiquer par ce pipe nommé.
Tu peux aussi remplacer ce pipe nommé par un descripteur de canal de message IPC system V.
ok, merci pour la suggestion, je vais me documenter.
un ami me proposait de creer un fichier /var/malib/59 qui contiendrait la clef ipc du processus 59, mais je me demande a quel point cela serait lent de passer par le systeme de fichier...
mouais, ça me paraît du même tonneau que les IPC system V.
Le problème avec le fait de passer par le système de fichier ou bien par les IPC system V, c'est qu'il faut détruire les ressources inutilisées.
mais bon dans quel cas utilise t on les IPC alors? je veux dire, si on peut assurer la communication inter processus avec des pipes nommes et des sockets unix, quel est l'interet des IPC si cela ajoute du travail et donc des "bugs" potentiels?
Ceci dit, n'es-tu pas en train de réinventer Corba ?
heu peut etre. je ne connais que de nom, mais la programmation ca consiste bien a recoder ce qui a deja ete code 100 fois, mais en moins beau et avec plus de "bugs", non?
-- Guillaume Desticourt
DINH Viêt Hoà wrote:
par exemple si le processus de pid 32 envoit un message au demon, qui
doit etre livre au processus de pid 59, comment mon demon pourrait il
creer un canal de communication entre lui meme et le processus 59
puisqu'il faut une clef commune?
Le démon va écouter sur un socket unix.
Les processus vont communiquer avec le démon par ce socket unix.
Lorsque tu vas créer tu vas initialiser ta connexion entre tes 2
processus, tu envoies à chacun en réponse l'identifiant commun à la
connexion, par exemple le nom pipe nommé qui sera créé.
Ils pourront ainsi communiquer par ce pipe nommé.
Tu peux aussi remplacer ce pipe nommé par un descripteur de canal de
message IPC system V.
ok, merci pour la suggestion, je vais me documenter.
un ami me proposait de creer un fichier /var/malib/59 qui contiendrait
la clef ipc du processus 59, mais je me demande a quel point cela serait
lent de passer par le systeme de fichier...
mouais, ça me paraît du même tonneau que les IPC system V.
Le problème avec le fait de passer par le système de fichier ou bien par
les IPC system V, c'est qu'il faut détruire les ressources inutilisées.
mais bon dans quel cas utilise t on les IPC alors? je veux dire, si on
peut assurer la communication inter processus avec des pipes nommes et
des sockets unix, quel est l'interet des IPC si cela ajoute du travail
et donc des "bugs" potentiels?
Ceci dit, n'es-tu pas en train de réinventer Corba ?
heu peut etre. je ne connais que de nom, mais la programmation ca
consiste bien a recoder ce qui a deja ete code 100 fois, mais en moins
beau et avec plus de "bugs", non?
par exemple si le processus de pid 32 envoit un message au demon, qui doit etre livre au processus de pid 59, comment mon demon pourrait il creer un canal de communication entre lui meme et le processus 59 puisqu'il faut une clef commune?
Le démon va écouter sur un socket unix. Les processus vont communiquer avec le démon par ce socket unix. Lorsque tu vas créer tu vas initialiser ta connexion entre tes 2 processus, tu envoies à chacun en réponse l'identifiant commun à la connexion, par exemple le nom pipe nommé qui sera créé.
Ils pourront ainsi communiquer par ce pipe nommé.
Tu peux aussi remplacer ce pipe nommé par un descripteur de canal de message IPC system V.
ok, merci pour la suggestion, je vais me documenter.
un ami me proposait de creer un fichier /var/malib/59 qui contiendrait la clef ipc du processus 59, mais je me demande a quel point cela serait lent de passer par le systeme de fichier...
mouais, ça me paraît du même tonneau que les IPC system V.
Le problème avec le fait de passer par le système de fichier ou bien par les IPC system V, c'est qu'il faut détruire les ressources inutilisées.
mais bon dans quel cas utilise t on les IPC alors? je veux dire, si on peut assurer la communication inter processus avec des pipes nommes et des sockets unix, quel est l'interet des IPC si cela ajoute du travail et donc des "bugs" potentiels?
Ceci dit, n'es-tu pas en train de réinventer Corba ?
heu peut etre. je ne connais que de nom, mais la programmation ca consiste bien a recoder ce qui a deja ete code 100 fois, mais en moins beau et avec plus de "bugs", non?
-- Guillaume Desticourt
Laurent Wacrenier
Guillaume Desticourt écrit:
mais bon dans quel cas utilise t on les IPC alors? je veux dire, si on peut assurer la communication inter processus avec des pipes nommes et des sockets unix, quel est l'interet des IPC si cela ajoute du travail et donc des "bugs" potentiels?
Les IPC System V ne sont réélement utilisables que sur des programmes persistants qui font le ménage de temps en temps dans les ressources.
mais bon dans quel cas utilise t on les IPC alors? je veux dire, si on
peut assurer la communication inter processus avec des pipes nommes et
des sockets unix, quel est l'interet des IPC si cela ajoute du travail
et donc des "bugs" potentiels?
Les IPC System V ne sont réélement utilisables que sur des programmes
persistants qui font le ménage de temps en temps dans les ressources.
mais bon dans quel cas utilise t on les IPC alors? je veux dire, si on peut assurer la communication inter processus avec des pipes nommes et des sockets unix, quel est l'interet des IPC si cela ajoute du travail et donc des "bugs" potentiels?
Les IPC System V ne sont réélement utilisables que sur des programmes persistants qui font le ménage de temps en temps dans les ressources.
Guillaume Desticourt
DINH Viêt Hoà wrote:
Si les IPC system V te limitent le nombre de resources créées, tu peux éventuellement passer par un processus central qui va se charger de créer les cannaux entre processus.
hum... tu veux dire un demon sur lequel tous les processus feraient leur msgsnd. mais que veux tu dire par creer un canal?
par exemple si le processus de pid 32 envoit un message au demon, qui doit etre livre au processus de pid 59, comment mon demon pourrait il creer un canal de communication entre lui meme et le processus 59 puisqu'il faut une clef commune?
Le démon va écouter sur un socket unix. Les processus vont communiquer avec le démon par ce socket unix. Lorsque tu vas créer tu vas initialiser ta connexion entre tes 2 processus, tu envoies à chacun en réponse l'identifiant commun à la connexion, par exemple le nom pipe nommé qui sera créé.
Ils pourront ainsi communiquer par ce pipe nommé.
heu apres reflexion je ne comprends toujours pas. j ai du mal... 1 - le demon ecoute sur une socket unix 2- l'application de pid 32 se connecte sur la socket et reclame une id IPC 3 - le demon cree la ressource IPC ayant pour uid l'uid du processus de pid 59, comme gid le gid du processus de pid 32, et mets les droits a 420 4 - le demon retourne l id IPC au processus de pid 32 5 - le demon contacte l'application 59 pour lui signaler une arrivee de message sur l IPC ayant cette ID
alors d'abord comment le 5 a t il lieu dans ton exemple? je veux dire comment le demon contacte t il l'application de pid 59? avec un signal pour que celle ci se connecte a la socket unix? et rien ne guarantit que c est bien le processus 59 qui va faire le msgrcv, cela pourrait etre tout processus ayant la meme uid, c est deja limiter les risques mais bon :(
Tu peux aussi remplacer ce pipe nommé par un descripteur de canal de message IPC system V.
je crois que c est ce que je vais faire car c est le seul moyen sous unix d'authentifier la source du message si j ai bien suivi, a part getpeereid qui n'est pas portable.
-- Guillaume Desticourt
DINH Viêt Hoà wrote:
Si les IPC system V te limitent le nombre de resources créées, tu
peux éventuellement passer par un processus central qui va se charger
de créer les cannaux entre processus.
hum... tu veux dire un demon sur lequel tous les processus feraient leur
msgsnd. mais que veux tu dire par creer un canal?
par exemple si le processus de pid 32 envoit un message au demon, qui
doit etre livre au processus de pid 59, comment mon demon pourrait il
creer un canal de communication entre lui meme et le processus 59
puisqu'il faut une clef commune?
Le démon va écouter sur un socket unix.
Les processus vont communiquer avec le démon par ce socket unix.
Lorsque tu vas créer tu vas initialiser ta connexion entre tes 2
processus, tu envoies à chacun en réponse l'identifiant commun à la
connexion, par exemple le nom pipe nommé qui sera créé.
Ils pourront ainsi communiquer par ce pipe nommé.
heu apres reflexion je ne comprends toujours pas. j ai du mal...
1 - le demon ecoute sur une socket unix
2- l'application de pid 32 se connecte sur la socket et reclame une id IPC
3 - le demon cree la ressource IPC ayant pour uid l'uid du processus de
pid 59, comme gid le gid du processus de pid 32, et mets les droits a 420
4 - le demon retourne l id IPC au processus de pid 32
5 - le demon contacte l'application 59 pour lui signaler une arrivee de
message sur l IPC ayant cette ID
alors d'abord comment le 5 a t il lieu dans ton exemple? je veux dire
comment le demon contacte t il l'application de pid 59? avec un signal
pour que celle ci se connecte a la socket unix?
et rien ne guarantit que c est bien le processus 59 qui va faire le
msgrcv, cela pourrait etre tout processus ayant la meme uid, c est deja
limiter les risques mais bon :(
Tu peux aussi remplacer ce pipe nommé par un descripteur de canal de
message IPC system V.
je crois que c est ce que je vais faire car c est le seul moyen sous
unix d'authentifier la source du message si j ai bien suivi, a part
getpeereid qui n'est pas portable.
Si les IPC system V te limitent le nombre de resources créées, tu peux éventuellement passer par un processus central qui va se charger de créer les cannaux entre processus.
hum... tu veux dire un demon sur lequel tous les processus feraient leur msgsnd. mais que veux tu dire par creer un canal?
par exemple si le processus de pid 32 envoit un message au demon, qui doit etre livre au processus de pid 59, comment mon demon pourrait il creer un canal de communication entre lui meme et le processus 59 puisqu'il faut une clef commune?
Le démon va écouter sur un socket unix. Les processus vont communiquer avec le démon par ce socket unix. Lorsque tu vas créer tu vas initialiser ta connexion entre tes 2 processus, tu envoies à chacun en réponse l'identifiant commun à la connexion, par exemple le nom pipe nommé qui sera créé.
Ils pourront ainsi communiquer par ce pipe nommé.
heu apres reflexion je ne comprends toujours pas. j ai du mal... 1 - le demon ecoute sur une socket unix 2- l'application de pid 32 se connecte sur la socket et reclame une id IPC 3 - le demon cree la ressource IPC ayant pour uid l'uid du processus de pid 59, comme gid le gid du processus de pid 32, et mets les droits a 420 4 - le demon retourne l id IPC au processus de pid 32 5 - le demon contacte l'application 59 pour lui signaler une arrivee de message sur l IPC ayant cette ID
alors d'abord comment le 5 a t il lieu dans ton exemple? je veux dire comment le demon contacte t il l'application de pid 59? avec un signal pour que celle ci se connecte a la socket unix? et rien ne guarantit que c est bien le processus 59 qui va faire le msgrcv, cela pourrait etre tout processus ayant la meme uid, c est deja limiter les risques mais bon :(
Tu peux aussi remplacer ce pipe nommé par un descripteur de canal de message IPC system V.
je crois que c est ce que je vais faire car c est le seul moyen sous unix d'authentifier la source du message si j ai bien suivi, a part getpeereid qui n'est pas portable.
-- Guillaume Desticourt
DINH Viêt Hoà
Le démon va écouter sur un socket unix. Les processus vont communiquer avec le démon par ce socket unix. Lorsque tu vas créer tu vas initialiser ta connexion entre tes 2 processus, tu envoies à chacun en réponse l'identifiant commun à la connexion, par exemple le nom pipe nommé qui sera créé.
Ils pourront ainsi communiquer par ce pipe nommé.
heu apres reflexion je ne comprends toujours pas. j ai du mal... 1 - le demon ecoute sur une socket unix 2- l'application de pid 32 se connecte sur la socket et reclame une id IPC 3 - le demon cree la ressource IPC ayant pour uid l'uid du processus de pid 59, comme gid le gid du processus de pid 32, et mets les droits a 420 4 - le demon retourne l id IPC au processus de pid 32 5 - le demon contacte l'application 59 pour lui signaler une arrivee de message sur l IPC ayant cette ID
alors d'abord comment le 5 a t il lieu dans ton exemple? je veux dire comment le demon contacte t il l'application de pid 59? avec un signal pour que celle ci se connecte a la socket unix? et rien ne guarantit que c est bien le processus 59 qui va faire le msgrcv, cela pourrait etre tout processus ayant la meme uid, c est deja limiter les risques mais bon :(
On peut sans doute supposer que les processus utilisant ce systeme de communication se sont tous connectés a ce démon.
-- DINH V. Hoa,
"l'alcool, ça me fait un effet bizarre" -- BNJ
Le démon va écouter sur un socket unix.
Les processus vont communiquer avec le démon par ce socket unix.
Lorsque tu vas créer tu vas initialiser ta connexion entre tes 2
processus, tu envoies à chacun en réponse l'identifiant commun à la
connexion, par exemple le nom pipe nommé qui sera créé.
Ils pourront ainsi communiquer par ce pipe nommé.
heu apres reflexion je ne comprends toujours pas. j ai du mal...
1 - le demon ecoute sur une socket unix
2- l'application de pid 32 se connecte sur la socket et reclame une id IPC
3 - le demon cree la ressource IPC ayant pour uid l'uid du processus de
pid 59, comme gid le gid du processus de pid 32, et mets les droits a 420
4 - le demon retourne l id IPC au processus de pid 32
5 - le demon contacte l'application 59 pour lui signaler une arrivee de
message sur l IPC ayant cette ID
alors d'abord comment le 5 a t il lieu dans ton exemple? je veux dire
comment le demon contacte t il l'application de pid 59? avec un signal
pour que celle ci se connecte a la socket unix?
et rien ne guarantit que c est bien le processus 59 qui va faire le
msgrcv, cela pourrait etre tout processus ayant la meme uid, c est deja
limiter les risques mais bon :(
On peut sans doute supposer que les processus utilisant ce systeme de
communication se sont tous connectés a ce démon.
Le démon va écouter sur un socket unix. Les processus vont communiquer avec le démon par ce socket unix. Lorsque tu vas créer tu vas initialiser ta connexion entre tes 2 processus, tu envoies à chacun en réponse l'identifiant commun à la connexion, par exemple le nom pipe nommé qui sera créé.
Ils pourront ainsi communiquer par ce pipe nommé.
heu apres reflexion je ne comprends toujours pas. j ai du mal... 1 - le demon ecoute sur une socket unix 2- l'application de pid 32 se connecte sur la socket et reclame une id IPC 3 - le demon cree la ressource IPC ayant pour uid l'uid du processus de pid 59, comme gid le gid du processus de pid 32, et mets les droits a 420 4 - le demon retourne l id IPC au processus de pid 32 5 - le demon contacte l'application 59 pour lui signaler une arrivee de message sur l IPC ayant cette ID
alors d'abord comment le 5 a t il lieu dans ton exemple? je veux dire comment le demon contacte t il l'application de pid 59? avec un signal pour que celle ci se connecte a la socket unix? et rien ne guarantit que c est bien le processus 59 qui va faire le msgrcv, cela pourrait etre tout processus ayant la meme uid, c est deja limiter les risques mais bon :(
On peut sans doute supposer que les processus utilisant ce systeme de communication se sont tous connectés a ce démon.
-- DINH V. Hoa,
"l'alcool, ça me fait un effet bizarre" -- BNJ
Guillaume Desticourt
bien. merci pour tes explications et pour ton temps. et merci a laurent pour sa precision.
cordialement,
-- Guillaume Desticourt
bien. merci pour tes explications et pour ton temps.
et merci a laurent pour sa precision.
