Ce n’est pas la première fois que je relève des imprécisions ou des erreurs plus ou moins graves sur ce site qui utilise massivement le JdH pour faire sa promo.
Je laisse méditer les lecteurs sur l’absurdité du parapgraphe sur le shebang (de fait je n’ai pas lu plus loin). On peut lancer un script avec n’importe quel interpréteur de commande quel que soit le shebang indiqué au début.
Celui-ci n’est là que pour des raisons pratiques : indiquer l’interpréteur à utiliser lorsque celui-ci n’est pas explicitement indiqué avant le script (python ./toto ou ksh ./toto par exemple).
Je ne contribue pas car je n’ai pas un niveau suffisant, malgré mes efforts. Néanmoins, je me forme un avis en la matière. Je le publie par des critiques ou remarques sur le JdH. J’avais un blogue sur lequel j’avais publié un ou deux articles hétéroclites peu intéressant. Je l’ai fermé par manque de compétences dans les domaines suivants : administration système, développement système, administration réseau. Ou dit plus simplement, par manque de compétences en développement Web (full-stack) et ce qui constitue ce que l’on nomme communément l’auto-hébergement de services. Je ne suis pas un pro. mais un amateur confirmé. Cela dit, vous me reprochez de ne pas contribuer par delà mes commentaires. Et ceux-ci ne sont visiblement pas pris en considération : aucune réponse ou prise en compte. Je conçois que mes commentaires ne soient pas forcément bien pris, voire des plus utiles. En conséquence, je ne laisse qu’un aperçu de ce que je pense. Il se pourrait qu’il y ait un problème de fond dans vos articles, comme l’a aussi relevé @bruno666, mais vous faites ce que vous voulez. Après tout, qui suis-je pour juger un travail que je ne fais pas ?
Par exemple, j’aurais pu ajouter qu’il ne faut pas systématiquement spécifier le nom de chemin absolu des commandes invoquées dans le script, en terme de sécurité. Normalement, on peut définir la valeur de la variable d’environnement PATH dans le script Shell. Et encore, c’est quelque chose de relativement simple à savoir. Je pense qu’au peut faire pire et élever le risque, lorsqu’on traite du niveau de sécurité informatique.
The restricted shell mode is only one component of a useful restricted environment. It should be accompanied by setting PATH to a value that allows execution of only a few verified commands (commands that allow shell escapes are particularly vulnerable), changing the current directory to a non-writable directory other than $HOME after login, not allowing the restricted shell to execute shell scripts, and cleaning the environment of variables that cause some commands to modify their behavior (e.g., VISUAL or PAGER).
Modern systems provide more secure ways to implement a restricted environment, such as jails, zones, or containers.
Bonjour,
Ce n’est pas la première fois que je relève des imprécisions ou des erreurs plus ou moins graves sur ce site qui utilise massivement le JdH pour faire sa promo.
Je laisse méditer les lecteurs sur l’absurdité du parapgraphe sur le shebang (de fait je n’ai pas lu plus loin). On peut lancer un script avec n’importe quel interpréteur de commande quel que soit le shebang indiqué au début. Celui-ci n’est là que pour des raisons pratiques : indiquer l’interpréteur à utiliser lorsque celui-ci n’est pas explicitement indiqué avant le script (python ./toto ou ksh ./toto par exemple).
Merci pour votre commentaire. Je vais tourner la phrase autrement.
En lisant, cela donne l’impression d’aborder des sujets en profondeur tout en les survolant. Hum !
J’adore prendre des remarques de gens qui ne contribuent en rien. Passez votre chemin
Je ne contribue pas car je n’ai pas un niveau suffisant, malgré mes efforts. Néanmoins, je me forme un avis en la matière. Je le publie par des critiques ou remarques sur le JdH. J’avais un blogue sur lequel j’avais publié un ou deux articles hétéroclites peu intéressant. Je l’ai fermé par manque de compétences dans les domaines suivants : administration système, développement système, administration réseau. Ou dit plus simplement, par manque de compétences en développement Web (full-stack) et ce qui constitue ce que l’on nomme communément l’auto-hébergement de services. Je ne suis pas un pro. mais un amateur confirmé. Cela dit, vous me reprochez de ne pas contribuer par delà mes commentaires. Et ceux-ci ne sont visiblement pas pris en considération : aucune réponse ou prise en compte. Je conçois que mes commentaires ne soient pas forcément bien pris, voire des plus utiles. En conséquence, je ne laisse qu’un aperçu de ce que je pense. Il se pourrait qu’il y ait un problème de fond dans vos articles, comme l’a aussi relevé @bruno666, mais vous faites ce que vous voulez. Après tout, qui suis-je pour juger un travail que je ne fais pas ?
Par exemple, j’aurais pu ajouter qu’il ne faut pas systématiquement spécifier le nom de chemin absolu des commandes invoquées dans le script, en terme de sécurité. Normalement, on peut définir la valeur de la variable d’environnement PATH dans le script Shell. Et encore, c’est quelque chose de relativement simple à savoir. Je pense qu’au peut faire pire et élever le risque, lorsqu’on traite du niveau de sécurité informatique.