Peut importe que le chemin soit tortueux, passe par trente applis qui redistribuent les fichiers dans tous les sens et que quinze procédures de vérifications automatiques se déclenchent - la question est "le stagiaire peut-il créer des fichiers sur un répertoire situé sur le serveur sans l'intervention d'un admin ?"
L'admin on s'en balance et c'est pas son soucis. On livre des briques spécifiées, packagées et compartimentées. Le problème de qui a contribué cette ligne ou ce fichier dans chaque brique ce n'est pas son problème et il ne peut et veut de toute facon pas le gérer. L'admin à papa, ca n'existe plus car ca ne scale pas et ca n'a pas de valeur ajouté bien au contraire. On livre des paquets intégrés aux systèmes cibles dans des repos spéciaux qui répondent aux specs, avec des processus de mise en prod/rollback automatique. L'admin traditionel ne peut pas suivre le dev de 200 briques, avec des dizaines/centaines/milliers de gars qui bossent. Il ne comprend même pas les besoins fonctionnels des briques. Par contre on intégre les admin dans les équipes de dev par ce qu'ils ont pleins de choses intéressantes à dire sur les contraintes opérationelles ou sécu. Ca permet de les prendres en compte dès la conception et pas une fois que ca plante et ca leur permet de gauler l'infra pour les besoins de leurs utilisateurs.
Si je prends ton exemple, il y a fort longtemps j'ai contribué quelques chapitres aux deux handbooks de FreeBSD. J'ai donc créé les fichiers avec mes petites mains, créé des patchs, puis envoyé des patchs sur le BTS, puis quelqu'un a poussé les patchs sur de CVS, puis quelqu'un d'autre à merger les commits dans les différentes branches, qui se sont finallement automatiquement retrouvés publiés sur le www de FreeBSD.org.
Donc tu penses qu'il y a un problème de sécu avec ce processus ? Je suis le stagiaire là ! Où faudrait-il mettre des ACLs ? L'admin de FreeBSD.org ne sait même pas que j'existe. D'ailleurs pourquoi il le devrait. Ce qui l'intêresse lui c'est qu'un handbook produise des fichiers html non modifiable/exécutable dans un répertoire précis du wwww/ et rien en dehors. Et c'est comme ca qu'on assure la sécurité. Que j'ai modifié le chapitre 2 c'est pas son soucis. C'est le soucis des commiters doc qui s'assurent de la qualité/sécurité de leur produit (j'aurais très bien pu mettre un lien pishing ou effacer un paragraphe ACL ou non).
Mais ils apportent 0 au niveau sécurité.
Si on va part là, les ACL c'est la même chose. Le mec qui efface des ressources par erreur alors qu'il a le droit bha voilà... Ce n'est pas la bonne réponse.
Les politiques de sécurité doivent s'appliquer aux briques pas aux personnes. Pas de raison de plus compartimenter telle ou telle personne à l'exécution, ce n'est pas ca l'unité logique. Chaque brique est responsable de ce qui se passe chez elle. L'infra la compartimente, l'empêche de faire ce quelle ne doit pas faire, et assure l'isolation entre les briques. Les personnes n'ont rien a voir là dedans. Après chaque brique prend la resonsabilité de sa qualité et s'occupe de la question des personnes.
Et quand le stagiaire a besoin de pouvoir écrire (même indirectement) sur un répertoire qui doit être lisible par Apache mais pas par le monde entier, on se retrouve très vite limité avec les droits Unix standard - sur toute machine (même mono utilisateur) les ACL devraient être activés par défaut sur toutes les partitions, et l'admin ne devrait les éteindre que si il a une excellente raison de le faire. Ce n'est pas le cas aujourd'hui.
Si tu bosses comme ca tu es resté dans les années 80 ou il y a un énorme problème d'organisation. Je t'invite à regarder les processus de release engineering modernes.
En l'occurence ici tu as une brique fonctionnelle qui doit être isolée des autres sur lequel travail un stagiaire (mais ca pourrait être n'importe qui...). Cette brique va livrer des artifacts bien définis qui seront déployés à un endroit et un contexte sécu précis. Ta sécurité vient de là. Que la brique fasse de la merde fonctionnellement on s'en balance. De toute facon le taff du mec c'est de la modifier et l'admin ni comprend rien. Par contre elle ne peut pas impacter le reste, elle ne peut pas sortir. Et l'équipe qui s'occupe de la brique à plutôt intêret à se surveiller. C'est comme ca qu'on assure à la fois la sécurité du système, la qualité fonctionnelle et qu'on arrête d'avoir des équipes d'admin qui coûtent le même prix que les équipes de devs sans aucune plus value. Il vaut mieux les occuper à faire des choses utiles et contribué à la qualité du système en amont non ?
[^] # Re: Tout va bien, je t'assure
Posté par ckyl . En réponse au journal Les BSD isolés. Évalué à 4.
L'admin on s'en balance et c'est pas son soucis. On livre des briques spécifiées, packagées et compartimentées. Le problème de qui a contribué cette ligne ou ce fichier dans chaque brique ce n'est pas son problème et il ne peut et veut de toute facon pas le gérer. L'admin à papa, ca n'existe plus car ca ne scale pas et ca n'a pas de valeur ajouté bien au contraire. On livre des paquets intégrés aux systèmes cibles dans des repos spéciaux qui répondent aux specs, avec des processus de mise en prod/rollback automatique. L'admin traditionel ne peut pas suivre le dev de 200 briques, avec des dizaines/centaines/milliers de gars qui bossent. Il ne comprend même pas les besoins fonctionnels des briques. Par contre on intégre les admin dans les équipes de dev par ce qu'ils ont pleins de choses intéressantes à dire sur les contraintes opérationelles ou sécu. Ca permet de les prendres en compte dès la conception et pas une fois que ca plante et ca leur permet de gauler l'infra pour les besoins de leurs utilisateurs.
Si je prends ton exemple, il y a fort longtemps j'ai contribué quelques chapitres aux deux handbooks de FreeBSD. J'ai donc créé les fichiers avec mes petites mains, créé des patchs, puis envoyé des patchs sur le BTS, puis quelqu'un a poussé les patchs sur de CVS, puis quelqu'un d'autre à merger les commits dans les différentes branches, qui se sont finallement automatiquement retrouvés publiés sur le www de FreeBSD.org.
Donc tu penses qu'il y a un problème de sécu avec ce processus ? Je suis le stagiaire là ! Où faudrait-il mettre des ACLs ? L'admin de FreeBSD.org ne sait même pas que j'existe. D'ailleurs pourquoi il le devrait. Ce qui l'intêresse lui c'est qu'un handbook produise des fichiers html non modifiable/exécutable dans un répertoire précis du wwww/ et rien en dehors. Et c'est comme ca qu'on assure la sécurité. Que j'ai modifié le chapitre 2 c'est pas son soucis. C'est le soucis des commiters doc qui s'assurent de la qualité/sécurité de leur produit (j'aurais très bien pu mettre un lien pishing ou effacer un paragraphe ACL ou non).
Si on va part là, les ACL c'est la même chose. Le mec qui efface des ressources par erreur alors qu'il a le droit bha voilà... Ce n'est pas la bonne réponse.
Les politiques de sécurité doivent s'appliquer aux briques pas aux personnes. Pas de raison de plus compartimenter telle ou telle personne à l'exécution, ce n'est pas ca l'unité logique. Chaque brique est responsable de ce qui se passe chez elle. L'infra la compartimente, l'empêche de faire ce quelle ne doit pas faire, et assure l'isolation entre les briques. Les personnes n'ont rien a voir là dedans. Après chaque brique prend la resonsabilité de sa qualité et s'occupe de la question des personnes.
Si tu bosses comme ca tu es resté dans les années 80 ou il y a un énorme problème d'organisation. Je t'invite à regarder les processus de release engineering modernes.
En l'occurence ici tu as une brique fonctionnelle qui doit être isolée des autres sur lequel travail un stagiaire (mais ca pourrait être n'importe qui...). Cette brique va livrer des artifacts bien définis qui seront déployés à un endroit et un contexte sécu précis. Ta sécurité vient de là. Que la brique fasse de la merde fonctionnellement on s'en balance. De toute facon le taff du mec c'est de la modifier et l'admin ni comprend rien. Par contre elle ne peut pas impacter le reste, elle ne peut pas sortir. Et l'équipe qui s'occupe de la brique à plutôt intêret à se surveiller. C'est comme ca qu'on assure à la fois la sécurité du système, la qualité fonctionnelle et qu'on arrête d'avoir des équipes d'admin qui coûtent le même prix que les équipes de devs sans aucune plus value. Il vaut mieux les occuper à faire des choses utiles et contribué à la qualité du système en amont non ?