Avec les ACL le mecs ne peut effacer que les fichiers sur lesquels il a les droits. Donc le mec peut lire le code HTML, mais n'avoir le droit que de modifier certains fichiers CSS. Alors que les fichiers sont lisibles aussi bien par le proxy nginx que par apache et qu'un autre stagiaire ne peut modifier que les fichiers images.
Ca doit bien scaler et être très productif de gérer les utilisateurs, au sens employé, qui font les modifications au niveau de la prod !
Tu te focalises sur la gestion des personnes alors que ce qui est important c'est la gestion des briques et de leurs interactions. Tu veux empêcher un mec particulier de modifier une brique où un boût de brique ? C'est pas à la prod de le faire. Par contre la prod elle peut décider d'isoler deux briques.
Bidouiller pour empêcher un stagiaire de modifier un fichier sur la prod, ca sent très mauvais pour l'orga. Comme tu le dis toi même, la fiabilité et la sécurité passe par une gestion/validation humaine de ce qui est livré. Processus en deux étapes. Conception du produit puis déploiement.
La surface d'attaque est l'ensemble de tous les répertoires que l'utilisateur (au sens uid) VCS peut lire ou écrire. Sans ACL cette surface est disproportionnée par rapport au besoin.
Donc tes ACL ne sont pas par utilisateur comme tu t'obstines à l'expliquer avec l'exemple du mauvais stagiaire qui pourrait suprimer un png alors qu'il doit faire que du css. Alors que ce n'est pas du tout pour ca qu'on s'en sert. C'est bien pour séparer les briques. On peut utiliser les ACLs mais tu peux aussi avoir deux UID différentes avec des instances différentes et reverse-proxifier, balancer ca dans des VM, où un milliard d'approches différentes en fonction des briques et technos (par ce que les ACL sur www on arrive vite aux limites de l'exemple).
Personne ne dit que les ACL ne servent à rien, bien au contraire. Mais la justification utilisées me laisse très perplexe. Vérouiller qui fait quelle modification sur la prod avec une granularité fichier/rep ca sent pas bon du tout. L'info du mec qui a fait le changement devrait être perdu depuis longtemps entre le VCS, le packaging et le déploiement et ce n'est pas là qu'il faut s'en soucier. D'ailleurs ton stagiaire il a un UID spécifique sur la prod ? Sinon pourquoi dire que c'est un stagiaire et pourquoi insister sur la relation avec les ACL alors que ce n'est pas la solution à ce problème ?
[^] # Re: Tout va bien, je t'assure
Posté par ckyl . En réponse au journal Les BSD isolés. Évalué à 1.
Ca doit bien scaler et être très productif de gérer les utilisateurs, au sens employé, qui font les modifications au niveau de la prod !
Tu te focalises sur la gestion des personnes alors que ce qui est important c'est la gestion des briques et de leurs interactions. Tu veux empêcher un mec particulier de modifier une brique où un boût de brique ? C'est pas à la prod de le faire. Par contre la prod elle peut décider d'isoler deux briques.
Bidouiller pour empêcher un stagiaire de modifier un fichier sur la prod, ca sent très mauvais pour l'orga. Comme tu le dis toi même, la fiabilité et la sécurité passe par une gestion/validation humaine de ce qui est livré. Processus en deux étapes. Conception du produit puis déploiement.
Donc tes ACL ne sont pas par utilisateur comme tu t'obstines à l'expliquer avec l'exemple du mauvais stagiaire qui pourrait suprimer un png alors qu'il doit faire que du css. Alors que ce n'est pas du tout pour ca qu'on s'en sert. C'est bien pour séparer les briques. On peut utiliser les ACLs mais tu peux aussi avoir deux UID différentes avec des instances différentes et reverse-proxifier, balancer ca dans des VM, où un milliard d'approches différentes en fonction des briques et technos (par ce que les ACL sur www on arrive vite aux limites de l'exemple).
Personne ne dit que les ACL ne servent à rien, bien au contraire. Mais la justification utilisées me laisse très perplexe. Vérouiller qui fait quelle modification sur la prod avec une granularité fichier/rep ca sent pas bon du tout. L'info du mec qui a fait le changement devrait être perdu depuis longtemps entre le VCS, le packaging et le déploiement et ce n'est pas là qu'il faut s'en soucier. D'ailleurs ton stagiaire il a un UID spécifique sur la prod ? Sinon pourquoi dire que c'est un stagiaire et pourquoi insister sur la relation avec les ACL alors que ce n'est pas la solution à ce problème ?