Forum Programmation.c Signaux C PHP UID et permissions

Posté par  .
Étiquettes : aucune
1
31
jan.
2012

Bonjour a tous
Je veux creer un processus en C qui repond à des requetes PHP
J'ai choisi de les faire communiquer avec des pipes nommés. Je souhaite utiliser pour cela SIGUSR1 pour dire au processus qu'il y a une requete PHP en attente.
Php a le UID 33 et le GID 33. Quand je lance mon processus, je peux le lancer en root ou avec mon UID 1000. Je me suis par ailleurs ajouté au groupe 33. (la commande groups le confirme).
Pb :
J'observe que quand je lance un call posix_kill avec SIGUSR1 sous php il me dit que je n'ai pas la permission. J'ai donc tenté la meme chose dans le processus avec posix_setuid(33) en le lancant en root ou 1000 mais le processus dit que je n'ai pas la permission
Qu'est ce qu il y a qui ne va pas ?
Merci pour vos reponses.
Emmanuel

  • # Quel est l'intérêt de SIGUSR1 ?

    Posté par  . Évalué à 2.

    Le pipe suffit pour la synchronisation.
    Le processus C n'a qu'à lire le pipe, il sera bloqué jusqu'à ce que des données y soient présentes.

    • [^] # Re: Quel est l'intérêt de SIGUSR1 ?

      Posté par  . Évalué à 4.

      Si un processus lit un pipe avec rien derrière, il ne bloque pas, le read renvoie juste 0, comme à la fin d'un fichier. Pour que ça bloque, il faudrai que quelqu'un ai ouvert le tube et n'écrive rien dedans. Ce serait vraiment mal que le processus fasse ça.

      Le seul mécanisme de blocage qu'il peut y avoir, c'est lorsque tu ouvre un pipe nommé fraichement crée en lecture : ton open() va bloquer jusqu'à que quelqu'un d'autre l'ouvre en écriture.

      Mais bon, de toute façon, avec un pipe, si il y a deux scripts PHP qui écrivent des choses en même temps, tu va te retrouver avec un mix des deux messages.

  • # Pas bien.

    Posté par  . Évalué à 5.

    Ce n'est pas une bonne idée d'utiliser des signaux pour faire des RPC. Les signaux peuvent être delayés, mis dans une queue voire oubliés, et ils posent des problèmes de concurrences assez difficile (quand un gestionnaire de signal s'exécute, ton programme est dans un état indéterminé, tes structures de données (ou celles de la libc) peuvent être dans un état incohérent (interrompu en pleine mise à jour)). Si tu veux quand même faire comme ça, il faut lire la page de manuel de kill(2), puis la page de manuel de setreuid(2).

    Pour corriger le vrai problème, je te conseille plutôt de regarder ce que tu peux faire avec fastcgi, les IPC, la mémoire partagée, les sockets (Unix ou INET*), pour ne citer qu'eux.

    • [^] # Re: Pas bien.

      Posté par  . Évalué à 1.

      Je plussoie largement. Les signaux me semblent trop « instables » pour être utilisés dans du dev web. Un signal de temps en temps, ça passe, plein de signaux d'un coup, ça casse, surtout si le traitement derrière est long. Les Sockets me semblent être une solution parfaite.

      • [^] # Re: Pas bien.

        Posté par  . Évalué à 0.

        Quant à moi je moinssoie, les sémaphores sont là pour ça…

        • [^] # Re: Pas bien.

          Posté par  . Évalué à 1.

          Tu voulais pas parler de masque de signaux, plutôt ?

  • # zeromq !

    Posté par  . Évalué à 4.

    Je te conseille de lire ces slides du dev de photon : http://notes.ceondo.com/conf/phptour2011/#1
    Il utilise zeromq qui permet de communiquer via des sockets unix,tcp,udp,ipc, ... dans différents langages.

    J'utilise zeromq sur mon projet perso en C++ et c'est vraiment pratique.

  • # le pourquoi du signal

    Posté par  . Évalué à 0.

    merci a tous pour votre aide.
    En fait mon processus a besoin de communiquer aussi avec des peripheriques (AX12 pour ne pas les citer) sur le port serie. Il passe son temps à s'occuper d'eux. De temps en temps une page php locale envoi un ordre au processus ou demande la lecture d'un etat d'un des peripheriques. Il ne peut pas y avoir de concurrence puisqu'il n'y aura qu'une seule page php locale. Ca me semblait donc une bonne idee car le processus ne DOIT PAS etre bloqué par le php. hors le write est bloqué par le read, etc.
    La question est donc quelle architecture pour ecouter 2 entrees différentes en meme temps ?
    Pour le pipe je vais donc voir la memoire partagee qui pourrait etre pas mal.
    Indépendamment de cela je ne comprends pas le pb de permission que j'ai : je vais lire setreid et l'autre lien proposé.
    Emmanuel

    • [^] # Re: le pourquoi du signal

      Posté par  . Évalué à 3.

      La question est donc quelle architecture pour ecouter 2 entrees différentes en meme temps ?

      Tu à largement le choix, mais attention ! les trolls veillent ;)

      Tu à le choix entre :

      • du poll/select() : tu leur file une liste de descripteurs de fichiers, et ce que tu veux surveiller dessus, et il te diront que par exemple, il y a des données en attente sur ton port série, et que ton read() ne bloquera pas. Ou il te diront que tu peux maintenant écrire sur le socket reliée à ton PHP ...
      • des pthreads : tu à simplement deux fonctions qui s'exécutent en même temps. Attention à synchroniser les deux lorsque les deux utilisent des variables/ressources partagées.
      • De l'asynchrone multithréadé (aio sous linux) : tu dit à ton programme "envoie ça", ça bloquera pas, mais ça sera envoyé en tache de fond, et ça t'appellera optionellement une fonction quand c'est fini. Ça à l'air simple, non ? Sauf que c'est exactement le même mécanisme pour recevoir ;)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.