Re: checkout.php intégré dans spip-c li

Je ne partage pas du tout ton point de vue.

Le compte root n'est pas fait pour distribuer des scripts à tout le
monde. Il a trop de droits.

Le jour où l'un de tes scripts aura un pb de sécu, tu auras laissé le
loup entrer dans la bergerie.

pour partager un script à X users, tu places tous tes users dans un
groupe, tes scripts dans un dossier user avec ce meme groupe qui a le
droit d'execution.

Dans ce cas, root n'intervient pas.

Ce que tu proposes, tu peux le faire sur ta machine locale, mais surtout
pas sur un serveur de prod.

Et cela n'a rien à voir avec "comment fonctionne un système unix" qui
propose justement de limiter les droits à des scripts pour qu'ils ne
puissent pas atteindre le coeur de ton systeme.

Et je ne parle pas des binaires qui sont encore plus obscures ;-)


Ce n'est que mon avis, et sur nos serveurs, je préfère fermer les portes
aux plus de monde possible.





Le 02/05/2020 à 22:58, RastaPopoulos a écrit :
> Le 02/05/2020 à 21:44, tofulm a écrit :
>> Sous linux, c'est une très mauvaise habitude que d'utiliser sudo pour
>> tous les scripts perso.
>>
>> spip-cli, composer, npm, checkout.php, ..., tous vos scripts sh ou php
>> ne doivent pas etre installés avec les droits root.
> C'est l'inverse de comment fonctionne un système unix justement.
>
> Un système unix c'est foncièrement *multi-utilisateurs* à la base. Et c'est évidemment encore plus évident… sur un vrai serveur (au sens le gros truc lointain sur internet). Mais ça se voit aussi vite quand on a un ordi pour la famille aussi, avec plusieurs comptes dessus.
>
> Donc quand on installe un nouveau logiciel, on l'installe *pour tous les utilisateurs*, pas juste pour soi. Sinon c'est anti écologique et surtout anti maintenable. L'admin doit l'installer pour tout le monde, c'est la base sur un système multi-utilisateurs.
>
> Tout le barda de npm, composer, etc, et ça vaut pour les snaps de merde, c'est la mauvaise habitude de penser qu'un système c'est que pour un utilisateur unique (un webdev dans son coin).
>
> Bah non, sur nos serveurs on peut avoir plusieurs utilisateurs, et c'est pas à chacun d'installer 15 fois le même outil. On installe qu'une seule fois Git que je sache. Ça devrait être pareil pour n'importe quel autre outil.
>
> En théorie, on devrait avoir de l'empaquetage pour spip-cli, sauf que ça doit pas être comme nos ZIP, il faudrait une routine pour générer un PHAR à chaque fois qu'on le fait évoluer. Et donc un fichier unique, à mettre dans les binaires globaux, pour tout le monde.
>
_______________________________________________
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip