Forum Linux.général PAM qui ne marche pas ?

Posté par .
Tags : aucun
0
16
déc.
2004
Mon fichier /etc/security/console.perms est correctement écrit et permet à tous les utilisateurs appartenant au groupe audio de pouvoir lire et écrire sur la carte son (via les fichiers /dev/sound/*, gérés par devfsd).


Voilà ce qu'il contient (je n'ai mis que les parties intéressantes):

=/dev/dsp* /dev/audio* /dev/midi*
/dev/mixer* /dev/sequencer* \
/dev/sound/* /dev/snd/* /dev/beep \
/dev/admm* \
/dev/adsp* /dev/aload* /dev/amidi* /dev/dmfm* \
/dev/dmmidi* /dev/sndstat

0660 0660 root.audio



Cette configuration a toujours fonctionné. Seulement voilà, depuis un certain temps, je ne me souviens malheureusement pas de l'élément déclencheur (même si je suspecte une mise à jour de PAM), ça ne marche pas aussi bien.


Si je me logue avec l'utilisateur user1 appartenant au groupe audio, les fichiers /dev/sound/* sont comme ceci (regarder les permissions et utilisateurs) :

crw-rw---- 1 user1 audio 14, 3 jan 1 1970 /dev/sound/dsp



Pour l'instant, tout va bien, ça marche comme prévu.

Maintenant, si l'utilisateur user2 du groupe audio se logue, avec ma configuration, le fichier /dev/sound/dsp devrait être comme ceci :

crw-rw---- 1 user2 audio 14, 3 jan 1 1970 /dev/sound/dsp



Sauf que, voici ce que j'ai :

crw-rw---- 1 user2 root 14, 3 jan 1 1970 /dev/sound/dsp



Je ne sais vraiment pas d'où ça peut venir.


Et a priori, ce n'est pas un problème spécifique à la carte son : le même genre de configuration est utilisé pour le lecteur cd ou le graveur par exemple.


Merci par avance pour vos réponses :)
  • # Udev

    Posté par . Évalué à 3.

    Salut

    Je n'ai jamais utilisé devfs, mais je suis passé récemment à udev. Tout a fonctionné de façon transparente, c'est à dire que les seuls opérations que j'ai eu à faire (et que j'avais faites auparavant) sont les suivantes :

    1) ajouter les personnes autorisées à utiliser la carte son dans le groupe audio (usermod -G audio,autre_groupe1,autre_groupe2 le_login_du_gars)

    2) donner les bonnes permissions sur les fichiers correspondants. Udev le fait directement, c'est configuré dans /etc/udev/permissions.d/udev.permissions sur ma Debian, avec snd/* et sound/* (voir dans /etc/udev/rules.d/udev.rules également)

    3) lancer udevd (/etc/init.d/udev start sous Debian).

    Tout ça pour te dire qu'avec udev (et je pensais que c'était le cas avec devfs), inutile de se prendre le chou avec /etc/security/console.perms, dont je n'ai jamais entendu parler avant :)
    • [^] # Re: Udev

      Posté par . Évalué à 2.

      Par contre, il me semble que udev n'est utilisable qu'avec le noyau 2.6 (bah oui, je suis toujours en 2.4, flemme du changement oblige :)

      Sinon, ce petit problème va peut-être m'encourager à migrer.

      Sinon, je ne me prend pas vraiment le chou parce que ce que j'ai dans mon /etc/security/console.perms est la configuration par défaut de ma Gentoo. Il suffit juste de mettre les bon users dans les bon groupes, ce que tu dois apparemment aussi faire avec udev.

      Seulement, avant ça marchait sans problèmes. Puis là, ça marche plus :D
    • [^] # Re: Udev

      Posté par . Évalué à 1.

      J'utilise udev sur ma gnetoo et je peux te dir que console.perms est pris en compte ...pas de doute la dessus
      • [^] # Re: Udev

        Posté par . Évalué à 2.

        Et quelle est la valeur ajoutée ?
  • # J'ai trouvé !

    Posté par . Évalué à 1.

    Ça y est, j'ai trouvé !

    En fait, la syntaxe du fichier console.perms a changé, de la même manière que la commande chown.

    En effet, la syntaxe n'est plus user.group mais user:group (avec un deux-points).

    Voilà, maintenant ça marche !

    J'espère que mon commentaire servira à quelqu'un d'autre qui aura le même problème que moi :)

Suivre le flux des commentaires

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