J'aimerais en savoir plus sur les droits d'accès qu'ont les utilisateurs d'une Redhat (7.3 en l'occurence) après l'install par défaut. En effet après avoir installé Login.app (que je préfère à xdm), mes utilisateurs ont moins de droits qu'avant (l'alias ll, le montage de disquettes et cdrom, le shutdown, les périphériques audio, ...). J'ai à peu près réussi à faire les modifs nécessaires pour retrouver ma config initiale (je galère juste pour le son...), mais où sont stockés tous ces paramètres et pourquoi ne sont-ils pas chargés si je lance X avec Login.app plutot qu'avec xdm ?

les droits de montage sont dans /etc/fstab avec l'option user
 
l'audio, tes users doivent appartenir au groupe audio
 
shutdown aucune idee?

 
Merci pour ton aide mais j'aimerais vraiment comprendre où est-ce que Redhat stocke toutes ces autorisations et en quoi c'est lié à xdm ?
Car c'est vrai qu'en rajoutant l'option user à /etc/fstab ca marche mais je m'explique pas pourquoi ca marchait deja avant sans cette option (mais en lancant X avec Xdm).
C'est avant tout par intérêt que je posais la question.
 
A part ça pour le son j'ai pas encore trop cherché mais déjà je n'ai pas de groupe audio. Mais bon c'est pas ca le problème pour ca j'ai qu'à chercher un peu...

[jfdsdjhfuetppo]--Message édité par oibaf2001 le 14-05-2002 à 23:00:33--[/jfdsdjhfuetppo]

Bon je ne comprends toujours pas la logique interne qui fait qu'après une install par défaut de redhat les utilisateurs ont pleins de droits (très pratiques) sans raison apparente.
 
Je poste juste pour préciser la marche à suivre pour le son, en fait c'etait assez simple et à base de groupe audio comme le suggérait apolon34 :
$ groupadd -r audio
$ usermod -G audio toto
$ chgrp audio /dev/audio
$ chgrp audio /dev/mixer
$ chgrp audio /dev/dsp
$ chmod g+rw /dev/audio
$ chmod g+rw /dev/mixer
$ chmod g+rw /dev/dsp
 
Je n'ai donc plus de problème mais bon tout ca n'etait pas l'objet de mon post initial j'aimerais quand même comprendre le pourquoi du comment.

Pour shutdown, j'ai bien une idée. J'utilise wdm en lieu et place de xdm, kdm ou autre. Pour éteindre le pc à partir de wdm, il faut être root. Cependant, on peut dire à wdm que n'importe qui, tant qu'il a un compte sur le pc, peut éteindre le pc: il faut changer une ligne dans /etc/X11/wdm/wdm-config:
DisplayManager*wdmRoot:         true
en  
DisplayManager*wdmRoot:         false
Je ne crois pas me tromper...

ca c'est parceque les serveurs de login sont lances en tant que root donc ils peuvent te permettre ce qu'ils veulent
 
par contre le reste(audio, mount) c'est pas eux qui s'en chargent

Personnellement pour le shutdown j'utilise Login.app (qui est à l'origine de ce thread car xdm le permettait pas) qui me satisfait pleinement. Il suffit de taper halt ou shutown comme login et le mot de passe de root. En ce qui me concerne je préfère que n'importe qui puisse éteindre ou rebooter l'ordi. J'ai donc apporté la modif suivante à la fonction SpecialCorrect() du fichier Input.cc (en rouge) :
Fonction SpecialCorrect :
// strcpy(tmp, NameBuffer);    
// strcpy(NameBuffer, "root" );
// c = Correct();
// strcpy(NameBuffer, tmp);
c = 1;
En espérant que ca serve a d'autres.
 
Sinon, concernant mon post initial je précise que je ne demande pas de l'aide pour résoudre mes innombrables problèmes actuels mais plutôt une explication à leur apparition du fait que j'utilise Login.app pltot que xdm (par défaut avec redhat). Pour l'instant je capte toujours pas    
 
Menfin, merci pour votre aide

Bon concernant le problème de son, j'ajoute un petit détail qui a son importance : à chaque démarrage du système, les fichiers /dev/audio, /dev/mixer, et /dev/dsp reprennent leurs droits d'origine :
$ ll /dev/audio
crw-------  1  root  root  14,  4 avr 11 16:25  /dev/audio
 
C'est vraiment très déroutant et même si je peux mettre un script qui va bien dans /etc/rc.d/rc.local, j'aimerais bien comprendre pourquoi Redhat vire ces 3 fichiers du groupe audio à chaque boot (et surtout comment y remédier proprement).
 
Je suis quand même assez surpris que sur un système linux certains droits d'accès soient réinitialisés  chaque boot au mépris des choix de l'admin... Dommage je commencais à apprécier la Redhat...

Je suis totalement d'accord, je répondais juste à apollon34 qui ne voyais pas d'où pouvait venir le probléme de shutdown.

Pour les droits sur le son et autre, utiliserais-tu devFS? Si je ne me trompe pas, il recrée les fichiers de /dev à chaque démarrage non?

Je n'utilise pas devFS (le support est désactivée dans le noyau)mais c'est peut-être mon tord justement. Toujours est-il que j'aimerais bien pouvoir configurer les droits d'accès aux périphériques pour mes utilisateurs, donc si qqn des infos à ce sujet je suis preneur.
J'ai remarqué à l'instant que l'accès à la lecture de cd-audio n'etait pas permise non plus. Dois-je déplacer /dev/cdrom du groupe disk pour le mettre dans le groupe audio ?
Je comprends pas qu'il soit si difficile de trouver de la doc à ce sujet : je dois quand même pas être le seul à avoir des droits réinitialisés à chaque boot

moi je pense que ton probleme vient de pam
 
je suis tombe sur quelques articles la dessus sur le wab
par contre desole j'ai pas d'url a te donner mais avec un man pam et en explorant le fichier de conf, tu devrais pouvoir y arriver !!
 
en esperant que ca t'aide...

Ok merci beaucoup pour le tuyau.
 
Bon effectivement j'ai cherché dans cette direction et j'ai maintenant une explication rationelle à tout ca : au login, Redhat va lire le fichier /etc/security/console.perms et met à jour les permissions des fichiers concernés (beaucoup de fichiers de /dev). La finalité c'est que quand un utilisateur se loggue, il prenne automatiquement les droits root pour ces fichiers ce qui est assez pratique.
 
Maintenant pourquoi cela ne marche t-il plus depuis que j'utilise Login.app au lieu de xdm pour me connecter ? Ben en guise de réponse voici un extrait du manuel de pam_console :
pam_console.so  is  designed  to  give users at the physical console (virtual terminals and local xdm-managed X sessions by default, but that is configurable) capabilities  that  they  would  not otherwise  have, and to take those capabilities away when the are no longer logged in at the console.
 
Voilà, en rouge l'explication mais maintenant j'aimerais bien savoir comment le login manager utilisé est configurable parce que là j'ai beau chercher je trouve plus