10.11 El Capitan Droit d'accès Mot de passe admin
- Créateur du sujet robert08
- Date de début
M
Membre supprimé 1060554
Invité
Je m'accorde avec ce principe. Mais ce qui me captive, ce sont les exceptions, parce que leur possibilité logique manifeste l'incohésion formelle d'un Système.
Supposons un administrateur qui serait amené à accorder sur des objets des ACE à des utilisateurs aussi bien qu'à des groupes, en plus des permissions POSIX.
- Il peut accorder sur un objet des ACE positives (de type allow readattr) à tous les utilisateurs et à tous les groupes (ou à quelques-uns seulement) sans qu'il y ait conflit formel (aucun utilisateur ne pâtira de l'ACE positive attachée à d'autres utilisateurs, non plus qu'à aucun groupe dont il est membre).
- il peut accorder sur le même objet des ACE négatives (de type deny delete) à quelques utilisateurs et des ACE positives (de type allow readattr) au reste des utilisateurs et à tous les groupes sans qu'il n'y ait non plus de conflit formel (aucun utilisateur non plus qu'aucun groupe ne pâtiront de l'ACE négative attachée à un simple utilisateur).
- mais s'il accorde sur le même objet une ACE négative à un groupe (de type deny delete), alors non seulement les utilisateurs simplement membres de ce groupe seront interdits de cette permission, mais de surcroît l'utilisateur propriétaire en titre de l'objet dans la mesure où il est aussi membre de ce groupe subira un effet restrictif secondaire : il devra s'authentifier par son mot-de-passe sur sa propre propriété, pour justifier le fait qu'il n'est pas qu'un simple membre du groupe subissant la restriction, mais qu'il est aussi l'user. Il en ira de même sur l'objet pour les membres d'un groupe à privilège, comme les admin (s'ils ont en tant qu'admin cette permission).
- il peut accorder sur le même objet des ACE négatives (de type deny delete) à quelques utilisateurs et des ACE positives (de type allow readattr) au reste des utilisateurs et à tous les groupes sans qu'il n'y ait non plus de conflit formel (aucun utilisateur non plus qu'aucun groupe ne pâtiront de l'ACE négative attachée à un simple utilisateur).
- mais s'il accorde sur le même objet une ACE négative à un groupe (de type deny delete), alors non seulement les utilisateurs simplement membres de ce groupe seront interdits de cette permission, mais de surcroît l'utilisateur propriétaire en titre de l'objet dans la mesure où il est aussi membre de ce groupe subira un effet restrictif secondaire : il devra s'authentifier par son mot-de-passe sur sa propre propriété, pour justifier le fait qu'il n'est pas qu'un simple membre du groupe subissant la restriction, mais qu'il est aussi l'user. Il en ira de même sur l'objet pour les membres d'un groupe à privilège, comme les admin (s'ils ont en tant qu'admin cette permission).
C'est ce dernier cas de figure qui a attiré mon attention, car il témoigne d'un conflit de statut créé par une ACE négative de groupe. Dans la mesure où tous les utilisateurs font partie du groupe universel le plus faible, qui est everyone, toute ACE négative affectant everyone se répercutera sur tous les utilisateurs (sauf root) en les obligeant à s'authentifier pour faire jouer cette permission sur l'objet - quand bien même seraient-ils membres d'un groupe supérieur en privilèges (comme admin) ou même l'user de l'objet.
Un administrateur avisé devrait donc s'interdire le cas de figure de l'ACE négative de groupe, afin de ne pas susciter de conflit formel obligeant des utilisateurs privilégiés membres du groupe à s'authentifier pour user de leur privilège sur l'objet, l'user en premier lieu. C'est sous ce rapport que ta notion d'« harmonisation » prend valeur de concept : garder une cohérence formelle du statut de l'utilisateur et de son appartenance à un groupe, en évitant les attributions contradictoires (comme, pour un même utilisateur : allow delete compris dans ses permissions POSIX en tant qu'user vs deny delete en tant qu'everyone).
[Il est à noter que sucrer les permissions POSIX de lecture / écriture / exécution à un groupe (everyone, par exemple) sur un dossier => drwxrwx--- user staff n'a aucun effet d'obligation à s'authentifier sur les utilisateurs qui, en plus d'appartenir à everyone, sont des membres de staff ou des admin, ou encore l'user - seules des ACE négatives affectant le everyone ont cette répercution formelle.]
Dernière édition par un modérateur:
Disons que l'administrateur avisé devra faire attention à ne pas créer des usines à gaz trop complexes (mais l'administrateur avisé est rare, finalement).
Nul doute qu'il saura aussi utiliser les règles de préséance entre droits classiques et ACL, d'une part, et entre ACE d'autre part.
Je suppose ainsi que l'administrateur, ayant appliqué une ACE de groupe restrictive sur un objet, n'aura pas grande difficulté à appliquer une ACE d'utilisateur réaffectant les droits à untel (ou unetelle) que la précédente supprime (utiliser la numérotation des ACE pour savoir laquelle va gagner (la veinarde), avec l'option +a# de chmod).
En soi, cela ressemble assez à la gestion très délicate des pare-feux (qui utilise des ACL aussi). On a tôt fait de n'y plus rien comprendre...
PS : Quand, en plus, on s'amuse avec les héritages d'ACE, ça devient encore plus vite corsé.
Nul doute qu'il saura aussi utiliser les règles de préséance entre droits classiques et ACL, d'une part, et entre ACE d'autre part.
Je suppose ainsi que l'administrateur, ayant appliqué une ACE de groupe restrictive sur un objet, n'aura pas grande difficulté à appliquer une ACE d'utilisateur réaffectant les droits à untel (ou unetelle) que la précédente supprime (utiliser la numérotation des ACE pour savoir laquelle va gagner (la veinarde), avec l'option +a# de chmod).
En soi, cela ressemble assez à la gestion très délicate des pare-feux (qui utilise des ACL aussi). On a tôt fait de n'y plus rien comprendre...
PS : Quand, en plus, on s'amuse avec les héritages d'ACE, ça devient encore plus vite corsé.
D
Deleted member 1099514
Invité
Une fois les données récupérées,il faudra quand même penser à le reformater pour profiter de cet espace de stockage supplémentaire.
