Rappelons aussi que le concept d'ACL est très puissant (granularité fine des autorisations et des interdictions), et qu'il est présent depuis de nombreuses années dans VMS, Windows, d'autres Unix, et probablement d'autres systèmes que je ne connais pas.
En l'absence d'ACL, sous Linux, on est obligé de créer un groupe d'utilisateurs pour chaque combinaison possible de gens et d'ensembles de fichiers auxquels ils peuvent avoir accès. La combinatoire devient très vite ingérable, ce qui limite les permissions à des scénarios assez simples, d'autant plus que le nombre de groupes auxquels un utilisateur peut appartenir est assez limité (16 ou 32, de mémoire). Simples, mais suffisants dans la plupart des cas. Pour les autres, il y a les ACL.
Exemple typique et concret :
Des équipes d'étudiants qui font un TP. Chaque équipe a un groupe Unix bien sûr, pour que les fichiers créés par ses membres soient lisibles des autres membres, et pour qu'à l'inverse les membres de l'équipe ne puissent pas aller lire les fichiers des autres équipes. Jusqu'ici tout va bien.
Arrivent les assistants de TP. S'il n'y avait qu'un assistant, il serait root ou un truc du genre et n'aurait pas de problème. Mais il y a beaucoup d'équipes, donc plusieurs assistants, et pour diverses raisons, on ne veut pas qu'ils partagent le même compte, encore moins le compte root.
Donc on galère à mettre les assistants dans tous les groupes d'élèves qu'ils doivent encadrer, on se confronte à la limite du nombre de groupe maximum par utilisateur, on galère à maintenir tout ça, et en plus c'est pas propre car l'assistant peut modifier les fichiers des élèves.
Avec les ACL, il suffit de donner le droit de lecture seule à l'assistant qui va bien sur les répertoires (et sous-répertoires) qui vont bien, et c'est tout.
[^] # Re: Et PAM ?
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Linux Slackware 11.0 est disponible. Évalué à 7.
En l'absence d'ACL, sous Linux, on est obligé de créer un groupe d'utilisateurs pour chaque combinaison possible de gens et d'ensembles de fichiers auxquels ils peuvent avoir accès. La combinatoire devient très vite ingérable, ce qui limite les permissions à des scénarios assez simples, d'autant plus que le nombre de groupes auxquels un utilisateur peut appartenir est assez limité (16 ou 32, de mémoire). Simples, mais suffisants dans la plupart des cas. Pour les autres, il y a les ACL.
Exemple typique et concret :
Des équipes d'étudiants qui font un TP. Chaque équipe a un groupe Unix bien sûr, pour que les fichiers créés par ses membres soient lisibles des autres membres, et pour qu'à l'inverse les membres de l'équipe ne puissent pas aller lire les fichiers des autres équipes. Jusqu'ici tout va bien.
Arrivent les assistants de TP. S'il n'y avait qu'un assistant, il serait root ou un truc du genre et n'aurait pas de problème. Mais il y a beaucoup d'équipes, donc plusieurs assistants, et pour diverses raisons, on ne veut pas qu'ils partagent le même compte, encore moins le compte root.
Donc on galère à mettre les assistants dans tous les groupes d'élèves qu'ils doivent encadrer, on se confronte à la limite du nombre de groupe maximum par utilisateur, on galère à maintenir tout ça, et en plus c'est pas propre car l'assistant peut modifier les fichiers des élèves.
Avec les ACL, il suffit de donner le droit de lecture seule à l'assistant qui va bien sur les répertoires (et sous-répertoires) qui vont bien, et c'est tout.