Discussion :

[Invité]

Bonjour,

Je suis néophyte sous Linux. Je m'en sers courament mais ne développe que depuis peu avec. J'aurais voulu faire beeper le haut-parleur de mon PC avec une procédure C. J'ai vu qu'on utilisait sous linux qq chose comme

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
/*beep.c*/
#include <stdlib.h>
#include <sys/types.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/kd.h>
 
int main(int argc, char *argv[])
{
   int fd, time, freq, arg;
   fd = open("/dev/tty0", O_RDONLY);
   if (argc > 2)
   {
       freq = atoi(argv[1]);
       time = atoi(argv[2]);
   } else {
       freq = 400; /* frequency in Hz */
       time = 100;  /* time in millisec */
   }
   arg = (time<<16)+(1193180/freq);
   return ioctl(fd,KDMKTONE,arg);
}

Je sais que je ne suis pas sur un forum C mais le choix du forum Linux est justifié : la procédure ci-dessus fonctionne en mode root mais ne produit aucun son en mode user. Si j'ai bien compris, l'explication en serait que le noeud tty est pour tous les utilisateurs autres que root en ReadOnly ... C'est donc cette caractéristique propre à Linux que j'aimerais "contourner". A lire divers forums, il semblerait que faire beeper son PC en mode simple user, et ceci indépendamment de la distribution choisie (kernel 2.6), impose des "contorsions", des adaptations particulières adaptées à chaque distribution, des solutions "maison"... Est-ce le cas ?

Windowsien, je m'initie sous Ubuntu pour me faire une idée (en Pascal et en C++). Quelque soit l'OS utilisé, j'imagine mal les utilisateurs devoir régler leur station de travail pour entendre le beep d'erreur ou de fin de travail d'une procédure du logiciel. Même si je suis séduit par Linux, je ne m'attendais pas à rencontrer un tel problème de programmation.

En réalité le problème n'est pas crucial mais sa méthode de résolution (ou non) m'en apprendra certainement beaucoup sur le monde linux et ses pratiques.

Mais je n'en suis pas là. Commençons par le début : Qq'1 pourrait-il me donner un début de piste ?

Merci d'avance. Cordialement. Gilles

[matafan]

Ouvre /dev/tty au lieu de /dev/tty0 (évidement ça ne marche que si tu exécutes ton programme dans un tty).

[ALT]

J'avais fait le même essai il y a quelques années.
En effet, il faut les droits administrateur pour pouvoir piloter un périphérique.

• Le plus simple est d'utiliser setuid(). C'est relativement sûr si l'UID de root n'est utilisé que le temps nécessaire à l'opération (ici, quelques lignes de code).
• Le mieux est de développer un pilote. Mais c'est un poil plus compliqué.

Attention : dans les deux cas, une erreur peut entraîner un plantage violent du système.

À titre d'exemple, une partie de mon programme, où AdrPortActif est l'adresse du port du HP & AdrPortFreq est l'adresse du chronomètre programmable permettant de régler la fréquence du son.

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
int main()
{
int UIDUtilisateur; // UID de l'utilisateur en cours
    UIDUtilisateur=getuid(); // svg de l'UID de l'utilisateur
    printf("ID utilisateur = %i\n",UIDUtilisateur);
    if (setuid(0)!=0) // on demande les privilèges administrateur
    { // Échec : les privilèges sont refusés
      printf("Droits administrateur refusés\n");
      exit(2);
    }
    else
    {
      /* Get access to the ports - opérations nécessitant les droits administrateur */
      if (ioperm(AdrPortActif, 1, 1))
          {
            perror("IOPerm");
            exit(1);
        }
      if (ioperm(AdrPortFreq, 2, 1)!=0)
          {
            perror("IOPerm");
            exit(1);
        }
        /** Fin des opérations nécessitant les droits administrateur **/
        /**  On rétablit donc les droits de l'utilisateur de base    **/
      if (setuid(UIDUtilisateur)!=0) printf("Droits utilisateur refusés\n"); // on réduit les droits du programme
        else printf("Droits utilisateur de base accordés. UID = %d\n",getuid());

[matafan]

Vos problèmes de droit c'est parce que vous n'êtes pas proprio du tty... Si comme je le suggère tu ouvres /dev/tty, qui représente ton tty, au lieu de /dev/tty0, tu ne devrais pas avoir ce problème.

Si tu veux quelque chose de portable, tu peux utiliser curses pour faire beeper ton terminal : man curs_beep

[ALT]

Chez moi :

crw-rw-rw- 1 root dialout 5, 0 2008-11-03 17:53 /dev/tty
crw-rw---- 1 root root 4, 0 2008-11-03 18:14 /dev/tty0
crw------- 1 root tty 4, 1 2008-11-03 17:38 /dev/tty1

Autrement dit, à part l'administrateur, personne n'est le proprio du périphérique.
Ce qui est normal, d'ailleurs.
Par contre, tty accorde le droit d'écriture à tout le monde, ce qui est différent.

Néanmoins, je ne vois pas en quoi l'usage de /dev/tty donne accès au HP (sauf, peut-être pour un simple bip, mais pas plus).
Faudra m'expliquer le rapport !

[matafan]

/dev/tty c'est un tty qui représente le tty du process courant, c'est tout. Comme tu peux le remarquer tout le monde à le droit de lire et d'écrire dans /dev/tty... Parce que c'est TON tty, donc pas besoin de contrôles d'accès.

Ensuite ce qu'on peut faire avec, je n'en sais rien... Je disais simplement que comme l'auteur du sujet arrivait à faire ce qu'il veut avec /dev/tty0, il devrait plutôt faire la même chose avec /dev/tty. Ca règlerait ses problèmes de droits.

[ALT]

Ben c'est là que j'ai des doutes : S'il peut faire ce qu'il veut en tant qu'administrateur, ce n'est pas sur le terminal qu'il agit, mais directement sur le HP.
Donc le type du - ou les droits attachés audit - terminal n'ont aucune influence sur le HP, ni sur aucun autre périphérique. Heureusement ! Tu imagines le boulevard que ça ouvrirait à un pirate ?

[matafan]

Il fait un ioctl sur le terminal...

[ALT]

Je ne suis pas sûr que ça lui donne le droit d'accéder à un périphérique.
J'ai même souvenir que ça ne sert à rien dans ce cas.

Même remarque que précédemment : HEUREUSEMENT ! S'il suffisait de faire un ioctl dans un terminal pour contrôler un périphérique...

[matafan]

Rien n'empèche le kernel de faire des contrôles supplémentaires dans l'ioctl, c'est sûr. Mais dans le cas présent ce sont les droits d'accès au fichier qui empèchent sont programme de marcher en user. D'ailleurs il fait pas un test dans son programme, mais s'il en faisait il verrait que c'est le open() qui échoue.

[Invité]

Bonjour,

Un petit passage rapide par le forum.

Merci à ALT pour sa réponse : j'étudierai à nouveau la question vendredi PM à partir du code transmis.

Je remercie également les autres intervenants pour leurs réponses. La conclusion que j'en tire pour l'instant laisse perplexe le néophyte en Linux que je suis : Linux serait conçu de telle manière que l'émission d'un beep -enfin pour être plus précis, la méthode retenue pour émettre un beep- pourrait mettre en cause la sécurité de l'OS et à ce titre, à l'arrivée, compte tenu des process engagés, la possibilité d'émettre ce fameux beep pour un utilisateur moyen a été "retirée" ipso facto par les concepteurs. C'est celà ?

Enfin pour répondre à "Il ne fait pas de test"... En effet, je suis tombé de haut, comme je l'ai écrit. Savez-vous comment on beep sur ma plate-forme de travail habituelle ? En une ligne ! Donc vendredi je ferai les tests pour mieux appréhender le problème et vérifier les étapes du code C...

Cordialement. Gilles