/ dev / hidraw: autorisations de lecture

Que dois-je faire pour avoir des autorisations de lecture sur / dev / hidraw *?

Je vois des choses au sujet des règles udev et vu ce sur le net, mais le monde de udev est comme une terre étrangère pour moi, et s'il y a une sorte d'une solution plus simple où je me suis juste ajouter à un groupe qui serait dandy ...

(Aperçu d'Ubuntu 13.10)

N'hésitez pas à reformuler la question - je ne suis pas trop enclin à ce que le `` hidraw '' se passe exactement.

ÉDITER:

H'okay, donc, juste quelques informations supplémentaires pour clarifier le problème: j'ai littéralement parcouru le code qui appelait la open()méthode POSIX , et j'ai obtenu les errnoautorisations insuffisantes. L'exécution catsur le fichier en tant qu'utilisateur normal entraîne une erreur d'autorisations insuffisante, tandis que l'exécution sous suentraîne une opération réussie (quoique dénuée de sens) cat.

MODIFIER MODIFIER:

Sur demande, je fournis le code correspondant avec l'appel POSIX. Il s'agit de la bibliothèque HIDAPI de Signal11 (fonction hid_open_path). J'espère que ce code est correct, car il est apparemment utilisé depuis un certain temps maintenant. J'ai ajouté un commentaire situé là où la errnolecture pertinente a eu lieu dans GDB.

hid_device *dev = NULL;

hid_init();

dev = new_hid_device();

if (kernel_version == 0) {
    struct utsname name;
    int major, minor, release;
    int ret;
    uname(&name);
    ret = sscanf(name.release, "%d.%d.%d", &major, &minor, &release);
    if (ret == 3) {
        kernel_version = major << 16 | minor << 8 | release;
        //printf("Kernel Version: %d\n", kernel_version);
    }
    else {
        printf("Couldn't sscanf() version string %s\n", name.release);
    }
}

/* OPEN HERE */
dev->device_handle = open(path, O_RDWR);

// errno at this location is 13: insufficient permissions

/* If we have a good handle, return it. */
if (dev->device_handle > 0) {

    /* Get the report descriptor */
    int res, desc_size = 0;
    struct hidraw_report_descriptor rpt_desc;

    memset(&rpt_desc, 0x0, sizeof(rpt_desc));

    /* Get Report Descriptor Size */
    res = ioctl(dev->device_handle, HIDIOCGRDESCSIZE, &desc_size);
    if (res < 0)
        perror("HIDIOCGRDESCSIZE");


    /* Get Report Descriptor */
    rpt_desc.size = desc_size;
    res = ioctl(dev->device_handle, HIDIOCGRDESC, &rpt_desc);
    if (res < 0) {
        perror("HIDIOCGRDESC");
    } else {
        /* Determine if this device uses numbered reports. */
        dev->uses_numbered_reports =
            uses_numbered_reports(rpt_desc.value,
                                  rpt_desc.size);
    }

    return dev;
}
else {
    /* Unable to open any devices. */
    free(dev);
    return NULL;
}

J'ai renoncé à courir en essayant de trouver un autre moyen de le faire que les règles udev, et à la place, j'ai juste appris un peu sur udev et écrit une règle de retournement. La ligne suivante a été placée dans un .rulesfichier (j'ai nommé le mien 99-hidraw-permissions.rules) situé sous /etc/udev/rules.d.

KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0664", GROUP="plugdev"

Fondamentalement, cela affecte tous les périphériques sortant du sous-système hidraw du noyau au groupe plugdevet définit les autorisations sur r / wr / wr (pour root [le propriétaire par défaut], plugdev et tout le monde respectivement). Avec moi-même ajouté au groupe plugdev, tout est dandy.

Pas autant que le cerveau qui fondait comme je m'y attendais. Les règles d'Udev semblent en fait assez simples ... Je veux dire, elles peuvent devenir ridicules si vous traitez avec des ID de produit individuels et ainsi de suite, mais elles semblent assez fous pour ce qu'elles font.

Pour comprendre quelque chose ... commencez à le savoir.

Ok, tout d'abord, voyons ce que hidrawsignifie et ce qui est composé de:

• hid (Human Interface Device): Un périphérique d'interface humaine ou HID est un type de périphérique informatique qui interagit directement avec les humains et qui, le plus souvent, reçoit des informations de la part des humains et peut fournir des résultats aux humains. _{source wikipedia}
• raw: Cela signifie brut , mais dans l'ambiance Linux, cela signifie aussi direct.

Nous pouvons en déduire qu'il hidraws'agit d'une méthode brute / directe pour accéder au cache . Voyons maintenant ce que nos systèmes en pensent:

$ ls -l /dev/hidraw*
crw------- 1 root root 251, 0 Aug  3  2013 /dev/hidraw0
crw------- 1 root root 251, 1 Aug  3  2013 /dev/hidraw1
crw------- 1 root root 251, 2 Aug  3  2013 /dev/hidraw2
$ file /dev/hidraw*
/dev/hidraw0: character special 
/dev/hidraw1: character special 
/dev/hidraw2: character special

Alors, qu'est-ce que cela character specialsignifie? Les fichiers de caractères spéciaux ou les dispositifs de caractères se rapportent aux dispositifs par lesquels le système transmet des données un caractère à la fois, par exemple getchar. _{Wikipédia est à nouveau notre ami.} Il en va de même cau début de la ls -lcommande.

Que dois-je faire pour avoir des autorisations de lecture sur / dev / hidraw *?

Alors, comment cela résout-il votre question? Pour accéder à, /dev/hidraw*vous devez utiliser l'implémentation C pour lire / écrire dans ce fichier. Mais, si vous voulez des informations sur les HID connectés, vous devriez regarder /sys/class/hidraw/hidraw*/. Exemple:

$ cat /sys/class/hidraw/hidraw2/device/uevent
DRIVER=hid-generic
HID_ID=0003:000015D9:00000A4C
HID_NAME= USB OPTICAL MOUSE
HID_PHYS=usb-0000:00:1d.1-2/input0
HID_UNIQ=
MODALIAS=hid:b0003g0001v000015D9p00000A4C

Tenez compte du fait que seul le noyau a un accès direct dans la plupart des cas aux périphériques, et vous ne devez utiliser que les appels fournis dans l'espace utilisateur pour communiquer avec ces périphériques.

Je vois des choses sur les règles udev et je l'ai vu sur le net, mais le monde d'udev est comme une terre étrangère pour moi

À moins que vous ne développiez un nouveau pilote / périphérique que vous ne devriez pas trop jouer udev, vous pouvez endommager votre cerveau de façon permanente.