Bon on va reprendre les quotes avec l'histoirique donc le contexte.
Sujet 1
toi
Notre cerveau est limité. Si c'est trop compliqué, ça nous échappe et on fait des bêtises. De plus, quand on a un problème avec des droits sous Windows, et bien, c'est légèrement galère à résoudre au vu de la compléxité : "ça vient d'où ? j'ai les bons droit sur ce répertoire... peut-être le répertoire parent ?
Moi
de comprendre comment fonctionne le mécanisme d'héritage des droits
Toi
Faudrait expliquer avant ce que tu entends par mécanisme d'héritage des droits !
Réponse
Lors de la création d'un nouvel objet les permissions appliquées à cet objet dépendent des permissions du parent, un fs étant un arbre.
L'algorithme, très simple au passage, qui détermine les permissions se trouvent dans man 5 acl et [1]. Tu sembles avancer que comprendre le système de permissions est difficile ce qui est faux. L'umask n'a rien de plus simple.
Toi
Tu m'explique en quoi le principe du root est dépassé ?
Moi
Pourquoi l'administrateur du serveur web/mail peut-il lire les fichiers de tout le monde ?
Toi
Faut arrêter de dire n'importe quoi. C'est de la mauvaise foi. Si tu ne veux pas que ton administrateur du serveur mail puisse lire les fichiers de tout le monde, tu peux le faire. Suffit de ne pas donner les droits r à other à tes fichiers !
Moi
voir mettre à jour les softs mail. Si tu veux réellement avoir un admin mail qui puisse faire son boulot sans le root c'est la plaie. Une tonne de setuid, des perms à fixer à la main partout etc.
Toi
Explique moi également comment tu comptes t'y prendre avec les ACLs.
Réponse
On parlait du problème du root d'UNIX et de la difficulté d'avoir des admins non tout puissant sur une machine. Quel rapport avec les ACL ? Évidement que ca ne résoud pas le problème puisqu'on ne parlait pas de ca.
Le problème est que le root sous UNIX est omniprésent. Dès que tu veux faire autre chose qu'éditer tes fichiers tu finis par devoir avoir des setuid partout, des fixes crados, des serveurs à qui l'ont donne 100x plus de droits qu'ils n'en ont besoin et qui les rendront si ca leur chante.
> Explique moi le reste alors. Je déteste que l'on m'affirme des trucs (même vrais) sans l'expliquer.
Tu ne connais manifestement même pas les solutions greffées sur les concepts UNIX pour fixer comme on peut les problèmes de sécurités qui n'avait pas été pris en compte lors de la conception. Il me semble que tu n'imagines même pas qu'il puisse y avoir d'autres approches ou que l'outil que l'on te donne actuellement n'est pas parfait et devrait être soit modifié soit changé.
Tu es un admin UNIX je ne dis pas que tu es mauvais admin, ton boulot c'est d'utiliser ce qu'on te donne pour essayer de résoudre les problèmes que tu as. Si tu ne vois pas de problème dans la conception bisounours de la sécurité d'UNIX y'a pas de problèmes tu ne dois pas en avoir les besoins. D'ailleurs on peut considérer que le besoin découle de l'existance de solutions. Tu adaptes tes problèmes pour soit solvables avec ce dont tu disposes.
Je te conseil quand même de la lecture intéressante sur le sujet qui te fera toucher du doigt les problèmes.
Comme je suis gentil, j'ai déjà compulsé un peu de doc pour toi il suffit de fouiller dans:
[^] # Re: ACL
Posté par ckyl . En réponse au journal Les droits sous Longhorn : un plagiat d'Unix ?. Évalué à 4.
Bon on va reprendre les quotes avec l'histoirique donc le contexte.
Sujet 1
toi
Notre cerveau est limité. Si c'est trop compliqué, ça nous échappe et on fait des bêtises. De plus, quand on a un problème avec des droits sous Windows, et bien, c'est légèrement galère à résoudre au vu de la compléxité : "ça vient d'où ? j'ai les bons droit sur ce répertoire... peut-être le répertoire parent ?
Moi
de comprendre comment fonctionne le mécanisme d'héritage des droits
Toi
Faudrait expliquer avant ce que tu entends par mécanisme d'héritage des droits !
Réponse
Lors de la création d'un nouvel objet les permissions appliquées à cet objet dépendent des permissions du parent, un fs étant un arbre.
L'algorithme, très simple au passage, qui détermine les permissions se trouvent dans man 5 acl et [1]. Tu sembles avancer que comprendre le système de permissions est difficile ce qui est faux. L'umask n'a rien de plus simple.
[1] http://wt.xpilot.org/publications/posix.1e/download.html(...)
Sujet 2
Toi
Tu m'explique en quoi le principe du root est dépassé ?
Moi
Pourquoi l'administrateur du serveur web/mail peut-il lire les fichiers de tout le monde ?
Toi
Faut arrêter de dire n'importe quoi. C'est de la mauvaise foi. Si tu ne veux pas que ton administrateur du serveur mail puisse lire les fichiers de tout le monde, tu peux le faire. Suffit de ne pas donner les droits r à other à tes fichiers !
Moi
voir mettre à jour les softs mail. Si tu veux réellement avoir un admin mail qui puisse faire son boulot sans le root c'est la plaie. Une tonne de setuid, des perms à fixer à la main partout etc.
Toi
Explique moi également comment tu comptes t'y prendre avec les ACLs.
Réponse
On parlait du problème du root d'UNIX et de la difficulté d'avoir des admins non tout puissant sur une machine. Quel rapport avec les ACL ? Évidement que ca ne résoud pas le problème puisqu'on ne parlait pas de ca.
Le problème est que le root sous UNIX est omniprésent. Dès que tu veux faire autre chose qu'éditer tes fichiers tu finis par devoir avoir des setuid partout, des fixes crados, des serveurs à qui l'ont donne 100x plus de droits qu'ils n'en ont besoin et qui les rendront si ca leur chante.
> Explique moi le reste alors. Je déteste que l'on m'affirme des trucs (même vrais) sans l'expliquer.
Tu ne connais manifestement même pas les solutions greffées sur les concepts UNIX pour fixer comme on peut les problèmes de sécurités qui n'avait pas été pris en compte lors de la conception. Il me semble que tu n'imagines même pas qu'il puisse y avoir d'autres approches ou que l'outil que l'on te donne actuellement n'est pas parfait et devrait être soit modifié soit changé.
Tu es un admin UNIX je ne dis pas que tu es mauvais admin, ton boulot c'est d'utiliser ce qu'on te donne pour essayer de résoudre les problèmes que tu as. Si tu ne vois pas de problème dans la conception bisounours de la sécurité d'UNIX y'a pas de problèmes tu ne dois pas en avoir les besoins. D'ailleurs on peut considérer que le besoin découle de l'existance de solutions. Tu adaptes tes problèmes pour soit solvables avec ce dont tu disposes.
Je te conseil quand même de la lecture intéressante sur le sujet qui te fera toucher du doigt les problèmes.
Comme je suis gentil, j'ai déjà compulsé un peu de doc pour toi il suffit de fouiller dans:
http://www.madchat.org/sysadm/linux/(...)
http://madchat.org/sysadm/kern/(...)
Et des projets interessant à survoler qui proposent souvent l'explication du pourquoi:
http://www.rsbac.org/why.php(...)
http://www.nsa.gov/selinux/info/faq.cfm(...)
http://www.grsecurity.net/features.php(...) (partie RBAC notament)
http://www.trustedbsd.org/home.html(...)
http://www.trustedbsd.org/docs.html(...)
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac.html(...)
http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/mac.(...)
http://www.linsec.org/(...)
http://www.isso.sparta.com/opensource/(...) (ancienement les NAIlabs plein de projets interessant)
http://www.isso.sparta.com/research/finished_projects/index.html(...)
Tout ceux là planchent sur comment adapter UNIX pour en faire quelque chose répondant plus aux besoins actuels.
Il existe d'autres systèmes tel que plan9 qui partent sur d'autres concepts, http://www.cs.bell-labs.com/sys/doc/auth.html(...)
Sur ce j'arrête la, la discution est devenue stérile