> Le nombre de fois ou je me suis retrouvé sous X sans acces au devices paske
C'est bien, tu dois être content.
Si tu veux ACL, t'installes ACL. Mais ACL ne résoud toujours pas le problème conflit. Si deux types accèdent à la même ressource (graver un CD), ça merde.
Avec des mecs comme toi, je vais militer pour la suppression des consoles et ne garder que X11.
> C'est anti unix
Tu pourrais aussi dire anti-gnu. T'es pas à un troll près.
Où tu as vu que les fichiers dans /dev ne doivent jamais changer de propriétaire ?
pam_console n'est qu'une partie de pam (c'est un "plugin" parmi d'autres). Si tu n'aimes pas pam_console (c'est subjectif) édites les fichiers /etc/pam.d/* et vires "session ... pam_console.so" . Un "grep" d'aidera à trouver rapidement ces fichiers (si tu connais grep).
Et voilà. C'est anti-Unix ça aussi ?
Pour le reste des caractéristiques de PAM, lis la doc et ne t'étales pas sur tes impressions car tu as utilisé une distribution qui utilise PAM.
> udev fait le boulot comme un grand:
> /etc/udev/permissions.d/udev.permissions
Ha Ha Ha.
Tu ne connais pas PAM ni udev. T'es charmant.
udev crée des fichiers à la volé et doit leur affecter les droits qui sont fixé généralement avec MAKEDEV (à la création/packaging de /dev). Mais MAKEDEV n'est pas forcément disponible (dans initrd ou en début de boot). De plus MAKEDEV a ses limites. Entre autre il gène les périphériques pour un nombre limité de périphériques avec des paires majeur/mineur _déjà_ connu. Avec udev tu peux avoir 5 000 disques durs. MAKEDEV n'a pas les droits pour 5 000 disques durs (problème des paires majeur/mineur préalloués qu'évite udev ; Linux 2.7 va peut-être virer toute notion de paires majeur/mineur pour en faveur d'un "id" ou "handler" (le nom n'est pas encore connu) alloué dynamiquement (1,2,3...)).
Donc, /etc/udev/permissions.d/udev.permissions n'est rien d'autre que MAKEDEV mais adapté à udev. Si tu regardes de plus près, udev.permissions à les MÊME permissions que celles que tu trouves dans /etc/makedev.d/ (fichier de config de MAKEDEV). Il défini les droits, owner et group par _défaut_. Il ne connait rien au login. Quelque soit la personne loggué, c'est toujours le même propriétaire du fichier spécial.
Dans udev de Fedora, il y a /etc/udev/permissions.d/ _ET_ pam_setowner pour avoir l'équivalent de pam_console.so . En effet, il faut faire le boulot de pam_console.so non au login ou au lancement d'une appli mais à lors de l'arrivé d'un nouveau périphérique. PAM ne supporte pas ça (PAM est déclenché par programme) et udev a été "hacké" pour conserver la logique de pam_console.so.
udev crée les fichiers en tenant compte de /etc/udev/permissions.d/ (équivalent de MAKEDEV) puis lance pam_setowner qui va, par exemple, mettre le propriétaire de /dev/cdrom à titi.
pam_setowner utilisera le fichier /etc/security/console.perms comme configuration (comme le fait pam_console.so). Encore un truc que tu ne connais pas mais ça ne t'empêche pas de juger ce qui est pro-Unix et Anti-Unix.
[^] # Re: Différences ?
Posté par Ayrton . En réponse à la dépêche Dropline Gnome 2.8 disponible (depuis le 07/10/2004). Évalué à 0.
C'est bien, tu dois être content.
Si tu veux ACL, t'installes ACL. Mais ACL ne résoud toujours pas le problème conflit. Si deux types accèdent à la même ressource (graver un CD), ça merde.
Avec des mecs comme toi, je vais militer pour la suppression des consoles et ne garder que X11.
> C'est anti unix
Tu pourrais aussi dire anti-gnu. T'es pas à un troll près.
Où tu as vu que les fichiers dans /dev ne doivent jamais changer de propriétaire ?
pam_console n'est qu'une partie de pam (c'est un "plugin" parmi d'autres). Si tu n'aimes pas pam_console (c'est subjectif) édites les fichiers /etc/pam.d/* et vires "session ... pam_console.so" . Un "grep" d'aidera à trouver rapidement ces fichiers (si tu connais grep).
Et voilà. C'est anti-Unix ça aussi ?
Pour le reste des caractéristiques de PAM, lis la doc et ne t'étales pas sur tes impressions car tu as utilisé une distribution qui utilise PAM.
> udev fait le boulot comme un grand:
> /etc/udev/permissions.d/udev.permissions
Ha Ha Ha.
Tu ne connais pas PAM ni udev. T'es charmant.
udev crée des fichiers à la volé et doit leur affecter les droits qui sont fixé généralement avec MAKEDEV (à la création/packaging de /dev). Mais MAKEDEV n'est pas forcément disponible (dans initrd ou en début de boot). De plus MAKEDEV a ses limites. Entre autre il gène les périphériques pour un nombre limité de périphériques avec des paires majeur/mineur _déjà_ connu. Avec udev tu peux avoir 5 000 disques durs. MAKEDEV n'a pas les droits pour 5 000 disques durs (problème des paires majeur/mineur préalloués qu'évite udev ; Linux 2.7 va peut-être virer toute notion de paires majeur/mineur pour en faveur d'un "id" ou "handler" (le nom n'est pas encore connu) alloué dynamiquement (1,2,3...)).
Donc, /etc/udev/permissions.d/udev.permissions n'est rien d'autre que MAKEDEV mais adapté à udev. Si tu regardes de plus près, udev.permissions à les MÊME permissions que celles que tu trouves dans /etc/makedev.d/ (fichier de config de MAKEDEV). Il défini les droits, owner et group par _défaut_. Il ne connait rien au login. Quelque soit la personne loggué, c'est toujours le même propriétaire du fichier spécial.
Dans udev de Fedora, il y a /etc/udev/permissions.d/ _ET_ pam_setowner pour avoir l'équivalent de pam_console.so . En effet, il faut faire le boulot de pam_console.so non au login ou au lancement d'une appli mais à lors de l'arrivé d'un nouveau périphérique. PAM ne supporte pas ça (PAM est déclenché par programme) et udev a été "hacké" pour conserver la logique de pam_console.so.
udev crée les fichiers en tenant compte de /etc/udev/permissions.d/ (équivalent de MAKEDEV) puis lance pam_setowner qui va, par exemple, mettre le propriétaire de /dev/cdrom à titi.
pam_setowner utilisera le fichier /etc/security/console.perms comme configuration (comme le fait pam_console.so). Encore un truc que tu ne connais pas mais ça ne t'empêche pas de juger ce qui est pro-Unix et Anti-Unix.