RE : Permissions spéciales
--- "Jean-Yves F. Barbier" <7ukwn@free.fr> a écrit :
Je ne suis pas sûr de partager ton point de vue,
Il faut faire la différence entre groupe utilisateur, et
groupe système.
(ex : le PIG et le GID de l'utilisateur et du groupe utilisateur
qui lui est associé resteront identiques.
Il ne s'agit pas de ce 'genre' de groupes.)
Je trouve le système de droit plus fin, et plus sûr.
Je ne vois pas de faille spécifique.
> pour des tas de raisons:
> * Pas mal d'admins oublient de révoquer un compte quand la personne
> part,
Oui, bon, on peut toujours oublier. Ceci dit, le nom de
l'utilisateur sera dans /etc/passwd, et on pourra toujours faire
ça plus tard. (le groupe de l'utilisateur sera
dans /etc/group)
Par ailleurs, c'est la méthode que j'ai adopté dans l'exemple
que j'ai fait : il ne s'agit
+pas d'un goupe utilisateur+,
dans le sens où, j'ai fait un groupe spécialement +pour+
la gestion de la permission, et non-créé automatiquement
comme ça se passe lorsque l'on crée un nouvel utilisateur.
C'est rattaché à aucune autre contingence. C'est juste une permission
pour un exécutable (éventuellement pour plusieurs), qui
a été contruite exprès, et seuelement pour ça.
Donc, même en oubliant de supprimer l'utilisateur, je ne voie
aucun problème.
Seul les utilisateurs restant, qui appartienne au groupe :
groupe_de_l'exécutable_un,
pourront continuer à exécuter l'exécutable_1,
et je ne vois là aucun problème.
De même, les groupes, sont listés dans /etc/group.
Man group fait état d'un bug à ce sujet, mais la page date
de 1992, et on est en 2007. C'était sûrement au tout
début de la notion de groupe.
> * Plusieurs programmes/daemons sont susceptibles de partager le même
> groupe,
Je ne parle pas d'un processus automatique, qui se ferait dans
mon dos, à mon insu, mais d'un groupe créé exprès pour,
qui fait ce qu'on lui dit (ce pour quoi il a été construit),
exactement, et seulement.
Donc, si plusieurs exécutables sont dans le groupe,
c'est que je les y ai mis.
++ D'accord, si tu ne te souviens plus des exécutables que tu as
mis dans le groupe ++
ça doit être ça que je n'avais pas compris envisagé.
D'accord, donc, dans ce cas, plus difficile à gérer.
Si on a oublié, on peut cependant écrire un script de maintenance,
avec du awk ou du sed sur un ls -l récursif du path.
> * Pour 2-3 users (famille), pourquoi pas; pas au-dessus de 20 (te
> rappelleras-tu ce que tu as bidouillé à ce niveau dans 1 ou 2
> ans?),
Ok, je comprends maintenant.
> * Le groupe peut avoir une portée beaucoup plus grande que prévue
> (adm) et
> non-connue (ou modifiée dans le temps)
Ne pas inscrire quelqu'un à un groupe
déjà existant : dont effectivement on ne peut pas savoir, ce qu'il
fait, ce qu'il fera.
Mais plutôt à :
mon_groupe_donnant_l'accès_à_l'arrosage_des_fleurs_X887F24
On sait à quoi il sert, on est sûr de pas se faire
piquer le nom.
> * Si tu crée deux users 'test1' & 'test2', et que tu rends 'test2'
> membre
> du groupe 'test1', il le resteras, même si tu détruit le compte
> 'test1',
Ça c'est pour partage ses fichiers, c'est pour le travail
collaboratif.
Il ne pourra exécuter que les programmes qui appartiennent au groupe
test1 ; il avait le droit avant, c'est cohérent.
> le groupe va survivre .... (=> les users suivants n'auront plus
> UID=GID)
Là, il s'agit d'un groupe par défaut pour tous les users.
Comme le group users sur certaines distributions.
Il ne s'agit plus d'accorder, au coup par coup, au cas par cas,
l'accès à une ressource... Je me trompe ?
Tous les nouveaux utilisateurs seront forcément membre
de "users", par exemple, et auront donc, automatiquement
tous les même droits.
Ça doit être ça la différence entre les "groupes utilisateur",
et les "groupes système", dont parle adduser.
En fait il s'agit de la même chose, c'est juste la +façon
dont on le gère+ qui diffère.
Dans un cas, le "groupe est associé à un utilisateur" :
un groupe, un utilisateur, PID=GID.
Ça c'est pour partager ses fichiers entre collègues.
Pour que user_1 puisse utiliser certaines ressources appartenant
à user_2, on iscrit +l'utilisateur+ user_1 dans le +groupe+
user_2, qui se trouve être le groupe dont le GID est le même
que le PID de user_2.
Dans l'autre cas, "le groupe est associé à une ressource",
un exécutable, une socket...
Il n'y a pas d'utilisateur associé à ce groupe. Du moins pas
forcément. Il y a un utilisateur pgsql, correspondant au groupe
pgsql, mais c'est utilisateur n'est pas un utilisateur réel,
il ne serta qu'à l'administrateur, lorsqu'il veut gérer pgsql,
à ce moment il fait su pgsql :
Justrement, et c'est peut être là que c'est +plus fin+ que +sudo+ :
en faisant su pgsql, il acquiert les droits pour gérer pgsql,
et seuelement les droits pour gérer pgsql.
Même root, après avoir fait su pgsql, peut faire:
rm -r /, sans que ce soit catastrophique pour le système.
Seul pgsql aura été affecté.
>
> >> Sudo est un outil autrement mieux adapté, et surtout "chirurgical"
> >> (tu peux
> >> laisser l'accès à un seul
> >
Donc, group : bien plus précis, et adapté que sudo.
Et sûr aussi.
Mais attention, il s'agit de "goupes système",
et non pas de "groupes utilisateurs".
Et de groupes créés, individuellement, chacuns pour la circonstance.
Et non de vagues groupes admin, ou autre, qui existent déjà,
et auquels on inscrit tel ou tel user
pour les besoins de la cause.
> > Avec le groupe aussi
> >
> >> programme/daemon/script)
>
> >
>
Donc, bien sûr, je me plante peut être du tout au tout.
Mais le seul inconvénient que je vois, c'est qu'il n'y a pas de
lieu où sont répertoriés les associations +telle
ressource appartient à tel group+,
Et que dans ce cas, le mieux, et la seule chose qu'on peut faire,
est de faire un gros ls -l pour connaitre les droits et les groupes
de chaque exécutable, fichier, socket...
Et de faire un script pour interroger ça.
Et agir ou signaler, le cas échéant.
FA
_______________________________
______________________________________________
>
> > Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers
> Yahoo! Mail
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> je ne sais pas si c'est comme chez gourdle; mais chez eux, rien
> n'interdit dans
> les conditions générales au provider de scanner le contenu des
> emails......
>
> --
> Clarke's Third Law:
> Any sufficiently advanced technology is indistinguishable from
> magic.
>
> G's Third Law:
> In spite of all evidence to the contrary, the entire universe
> is composed of only two basic substances: magic and bullshit.
>
> H's Dictum:
> There is no magic ...
>
>
___________________________________________________________________________
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses
http://fr.answers.yahoo.com
Reply to: