> Tu essayes de mettre en pratique une philosophie windows sur une philosophie unix. Faut arrêter de penser que les 2 systèmes doivent se ressembler.
Je vais te decevoir je n'ai jamais utilisé de windows supportant les ACL. Ma seule expérience de Windows c'est un Win98 pendant 6 mois.
> On s'en est sorti avec des solutions plus ou moins bonne. Mais on en est pas mort.
l'exemple du binome est reproductible dans des environements un tantinet plus critique qu'une université. On parle de sécurité la.
> De plus, quand on a un problème avec des droits sous Windows
Je ne parle pas de Windows, je ne sais pas si leur implémentation est, feu, POSIX 1003.1E compliant. Je parle du mécanisme d'ACL que tout le monde utilise même si le standard est passé à la trappe. Si tu n'es pas capable de comprendre comment fonctionne le mécanisme d'héritage des droits, soit tu es incompétant soit ce n'est pas aàtoi de se soucier de ce problème.
> Il a juste besoin de droit suffisant au démarrage pour pouvoir utiliser le port 80 qui reste un port privilégié.
Pourquoi un processus d'apache à la possibilite de lire /dev/kmem ou tout ce qui lui semble bon tout au cours de son exécution ? (apache ne drop pas entièrement ses privilèges puisque ses fils doivent binder le 80)
> 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 !
L'administrateur mail doit pouvoir relancer l'imap, le pop, le smtp. Pouvoir editer les fichiers de conf, les certificats. Faire joujou avec le spool, 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.
> Pour protéger root de lui-même !
Ok j'ai compris le niveau... Tu ne semble strictement rien connaitre à ces solutions.
> De plus, ta réflexion est pour tous les OS.
Ma reflection porte sur le fait que l'on pense que la vision d'UNIX est toujours juste. Ton message en est l'exemple typique. La plupart des gens, et moi le premier, ont toujours pensé en terme UNIX. Ils ont appris avec, ils evoluent avec. On ne réfléchit donc plus au problème de base, mais on énonce le problème avec la seule sémantique que l'on connait. Et si cela ne marche pas bha "on en est pas mort".
Comme on dit quand on n'a qu'un marteau tout les problèmes ressemblent à des clous. Il te semble naturel qu'un démon système ait besoin d'être "dieu" sur la machine pour se lancer puis de dropper ses privilèges si bon lui semble. Pour moi c'est une solution naturelle dans un monde qui ne propose pas d'autre alternative. C'est la bonne manière de faire dans le monde UNIX. D'un point de vue philosophique c'est une horreur.
[^] # Re: ACL
Posté par ckyl . En réponse au journal Les droits sous Longhorn : un plagiat d'Unix ?. Évalué à 3.
Je vais te decevoir je n'ai jamais utilisé de windows supportant les ACL. Ma seule expérience de Windows c'est un Win98 pendant 6 mois.
> On s'en est sorti avec des solutions plus ou moins bonne. Mais on en est pas mort.
l'exemple du binome est reproductible dans des environements un tantinet plus critique qu'une université. On parle de sécurité la.
> De plus, quand on a un problème avec des droits sous Windows
Je ne parle pas de Windows, je ne sais pas si leur implémentation est, feu, POSIX 1003.1E compliant. Je parle du mécanisme d'ACL que tout le monde utilise même si le standard est passé à la trappe. Si tu n'es pas capable de comprendre comment fonctionne le mécanisme d'héritage des droits, soit tu es incompétant soit ce n'est pas aàtoi de se soucier de ce problème.
> Il a juste besoin de droit suffisant au démarrage pour pouvoir utiliser le port 80 qui reste un port privilégié.
Pourquoi un processus d'apache à la possibilite de lire /dev/kmem ou tout ce qui lui semble bon tout au cours de son exécution ? (apache ne drop pas entièrement ses privilèges puisque ses fils doivent binder le 80)
> 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 !
L'administrateur mail doit pouvoir relancer l'imap, le pop, le smtp. Pouvoir editer les fichiers de conf, les certificats. Faire joujou avec le spool, 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.
> Pour protéger root de lui-même !
Ok j'ai compris le niveau... Tu ne semble strictement rien connaitre à ces solutions.
> De plus, ta réflexion est pour tous les OS.
Ma reflection porte sur le fait que l'on pense que la vision d'UNIX est toujours juste. Ton message en est l'exemple typique. La plupart des gens, et moi le premier, ont toujours pensé en terme UNIX. Ils ont appris avec, ils evoluent avec. On ne réfléchit donc plus au problème de base, mais on énonce le problème avec la seule sémantique que l'on connait. Et si cela ne marche pas bha "on en est pas mort".
Comme on dit quand on n'a qu'un marteau tout les problèmes ressemblent à des clous. Il te semble naturel qu'un démon système ait besoin d'être "dieu" sur la machine pour se lancer puis de dropper ses privilèges si bon lui semble. Pour moi c'est une solution naturelle dans un monde qui ne propose pas d'autre alternative. C'est la bonne manière de faire dans le monde UNIX. D'un point de vue philosophique c'est une horreur.