Quand le client Steam sur Linux efface toutes vos données

Quand le client Steam sur Linux efface toutes vos données

Le rm -f est à manier avec parcimonie

Avatar de l'auteur
Sébastien Gavois

Publié dans

Logiciel

19/01/2015 3 minutes
106

Quand le client Steam sur Linux efface toutes vos données

Le client Linux de Steam contiendrait un bug des plus gênants qui pourrait entrainer la suppression de toutes vos données lorsque le répertoire d'installation est modifié manuellement. Valve indique à plusieurs de nos confrères avoir eu des retours similaires de la part de plusieurs utilisateurs et être sur la brèche.

En décembre 2012, et après des mois voire des années d'attente, Steam débarquait officiellement sur Linux, pour tout le monde. Depuis, les choses avancent doucement avec l'arrivée de nouveaux jeux et la prise en charge de périphériques supplémentaires. Mais, depuis ce week-end, le client Linux de Steam est sous le feu des projecteurs à cause d'un bug relativement gênant pouvant entrainer la perte pure et simple de toutes vos données. 

Si vous changez le répertoire par défaut de Steam pour Linux, attention

En effet, un utilisateur sous le pseudonyme de Keyvin détaille sa mésaventure sur le dépôt GitHub de Steam pour Linux. Il a tout d'abord déplacé le répertoire d'installation par défaut de Steam (/home/user/.local/steam) vers un autre emplacement, /media/user/BLAH, en ajoutant évidemment un lien symbolique afin d'établir la liaison entre les deux dossiers.

Keyvin explique le déroulement de son histoire : « j'ai lancé Steam. Il n'a pas démarré. Il m'a proposé de parcourir le système, mais n'a rien trouvé lorsque j'ai indiqué le nouvel emplacement. Steam a planté. Je l'ai redémarré. Il s'est réinstallé tout seul et tout semblait fonctionner correctement ». Problème, Keyvin découvre que Steam aurait effacé l'intégralité des données de son compte utilisateur, en remontant jusqu'à la racine. 

Quand la commande rm -rf est utilisée avec un peu trop de liberté

Dans les commentaires, certains utilisateurs pointent du doigt une des lignes de code du client Steam pour Linux, qui pourrait être à l'origine de ce problème. Ligne 468 en effet, un « rm -rf "$STEAMROOT/"* » se baladerait, permettant d'effacer le dossier de Steam, ainsi que toute l'arborescence qui en découle. Or, si la variable « STEAMROOT » est vide pour une raison ou pour un autre, cette commande se transformerait en  « rm -rf "/"* » qui a pour effet de tout effacer, un peu à la manière d'un « Format c: ».

De son côté, Valve a envoyé un communiqué de presse à plusieurs de nos confrères américains, dont PC World par exemple. La société indique que, « jusqu'à présent, nous avons eu une poignée d'utilisateurs qui ont signalé ce problème après avoir déplacé manuellement leur répertoire d'installation de Steam. Nous n'avons pas été en mesure de reproduire ce bug, mais nous sommes en train d'ajouter des étapes de vérification supplémentaires afin de s'assurer que cela ne puisse plus arriver pendant que nous continuons notre enquête. » Valve demande ensuite aux personnes concernées de les contacter par mail.

106

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Si vous changez le répertoire par défaut de Steam pour Linux, attention

Quand la commande rm -rf est utilisée avec un peu trop de liberté

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (106)


Outch méchant le bug.


Vivement les applications sandboxe sous Linux.








Nxi a écrit :



Or, si la variable « STEAMROOT » est vide pour une raison ou pour un autre, cette commande se transformerait en « rm -rf “/”* » qui a pour effet de tout effacer, un peu à la manière d’un « Format c: ».







Si le script n’est pas lancé en root, tu ne perds “que” les données utilisateurs ce qui est quand même bien grave (perso je préfère perdre le système) mais on est pas au formatage non plus.



C’est une sacrée boulette de la part de VALVE. Et franchement avec toutes les blagues autour du “rm -rf /” c’est étonnant de voir ce genre d’erreur encore arriver.



Encore une fois la preuve que Linux est beaucoup plus dangereux que Windows&nbsp;<img data-src=" />


Ca se fait tout aussi bien sous windows :)



Y’a pas de garde fous, en mode admin, et même en mode user, y’a moyen de faire un ménage plus que gênant.


la preuve que linux n’est pas fait pour jouer.








ar7awn a écrit :



la preuve que linux n’est pas fait pour jouer.





Lol





En effet, un utilisateur sous&nbsp;le pseudonyme de&nbsp;Keyvin&nbsp;détaille&nbsp;sa mésaventure



Ça ressemble à une blague-troll sur JV.com&nbsp;<img data-src=" />


C’est encore du teasing pour HL3 ?



<img data-src=" />


[HS]Chaque fois que j’entends parler de cette commande ça me rappelle un netbook sous distrib’ Linux vendu à une époque à Planet Saturn sur lequel le terminal s’ouvrait en root sans aucun mot de passe…



Et là je peux vous dire que ça démange de tapoter ces quelques caractères et voir la réaction des vendeurs après. <img data-src=" /> [/HS]





Concernant la news, ça veut dire que Steam a un accès root sur tout le système ?


attention, tu devrais tailler ta barbe, si elle commence à descendre plus bas que ton cou, c’est mauvais signe.








ar7awn a écrit :



la preuve que linux n’est pas fait pour jouer.





Je dirai plutôt “La preuve que chez Valve on ne sait pas faire un script shell”. Ça n’a rien à voir avec Linux, on peut très bien effacer toutes les données d’un disque Windows avec un script pourri aussi.

Heureusement, le patch d’urgence est rapide à mettre en place : ouvrir le script, mettre # devant le rm -rf en question et sauver le script.





rm -rf “\(STEAMROOT/"* could be evaluated as rm -rf "/"* if \)STEAMROOT is empty.



&nbsp;

Ouh que c’est moche <img data-src=" />








Takaï a écrit :



Concernant la news, ça veut dire que Steam a un accès root sur tout le système ?



A priori non vu que ca n’efface que les données utilisateurs (donc le /home et toutes les données sur lesquelles l’utilisateur à les droits d’ecritures).



Si STEAM a besoin d’être root pour fonctionner, autant ne pas l’installer <img data-src=" />









FeathersMG a écrit :



Heureusement, le patch d’urgence est rapide à mettre en place : ouvrir le script, mettre # devant le rm -rf en question et sauver le script.

passer a windows





<img data-src=" />

<img data-src=" />



Moi je dirais : “la preuve que les scripts bash sont le mal”








Takaï a écrit :



Concernant la news, ça veut dire que Steam a un accès root sur tout le système ?





Non, ça se lance juste avec les droits du compte utilisateur courant.

Après, si des gens lancent Steam en étant root, ben que dire … ils feraient mieux de retourner sous Windows. <img data-src=" />









seb2411 a écrit :



Vivement les applications sandboxe sous Linux.





Ou un profil seLinux pour plus qui se lance en unconfined_u.



Enfin AppArmor plutot vu que Steam ne supporte officiellement que’Ubuntu



Cela existe déjà depuis longtemps sous Linux. Docker et cie sont des exemples récents et très complets, mais chroot permet déjà de cloisonner le système de fichier vu par un programme en limitant ses accès…








FeathersMG a écrit :



Non, ça se lance juste avec les droits du compte utilisateur courant.

Après, si des gens lancent Steam en étant root, ben que dire … ils feraient mieux de retourner sous Windows. <img data-src=" />





rien de tel qu’un bon

chmod 777 /*

chmod 777 //

chmod 777 ///*



:p









CryoGen a écrit :



A priori non vu que ca n’efface que les données utilisateurs (donc le /home et toutes les données sur lesquelles l’utilisateur à les droits d’ecritures).



Si STEAM a besoin d’être root pour fonctionner, autant ne pas l’installer <img data-src=" />









FeathersMG a écrit :



Non, ça se lance juste avec les droits du compte utilisateur courant.

Après, si des gens lancent Steam en étant root, ben que dire … ils feraient mieux de retourner sous Windows. <img data-src=" />







C’est bien ce qu’il me semblait. J’ai été induit en erreur par cette phrase :





cette commande se transformerait en « rm -rf “/”* » qui a pour effet de tout effacer, un peu à la manière d’un « Format c:





Du coup en dehors d’un Steam avec droits root je voyais pas trop… D’où ma question. ^^









FeathersMG a écrit :



Non, ça se lance juste avec les droits du compte utilisateur courant.

Après, si des gens lancent Steam en étant root, ben que dire … ils feraient mieux de retourner sous Windows. <img data-src=" />





Valve veut vider le contenu de son STEAMPATH, À partir de là en C, en Bash, VisualBasic ou en Batch si c’est mal codé le résultat sera le même.









GentooUser a écrit :



Ou un profil seLinux pour plus qui se lance en unconfined_u.



Enfin AppArmor plutot vu que Steam ne supporte officiellement que’Ubuntu









RichardD a écrit :



Cela existe déjà depuis longtemps sous Linux. Docker et cie sont des exemples récents et très complets, mais chroot permet déjà de cloisonner le système de fichier vu par un programme en limitant ses accès…





Oui ça existe est c’est dispos et ca marche bien, mais c’est pas encore utilise dans les applications de manière systématique. Je sais même pas dans quelle mesure les gestionnaires de paquets peuvent gérer ça. Je sais qu’Ubuntu mobile propose les clickpackage base sur du Deb et qui sont sandboxe. Mais j’ai pas vu d’autres alternatives pour le moment. Ca va surement arriver mais il faudra encore un peu de temps.





En effet, un utilisateur sous&nbsp;le pseudonyme de&nbsp;Keyvin détaille&nbsp;sa mésaventure



Ouais mais avec un prénom pareil aussi, il cherche le gars…. <img data-src=" />








CryoGen a écrit :



A priori non vu que ca n’efface que les données utilisateurs (donc le /home et toutes les données sur lesquelles l’utilisateur à les droits d’ecritures).



Si STEAM a besoin d’être root pour fonctionner, autant ne pas l’installer <img data-src=" />





+1000.









Takaï a écrit :



Concernant la news, ça veut dire que Steam a un accès root sur tout le système ?







Non, uniquement pour l’installation de quelques libraires lorsqu’on l’installe, ensuite il a des droits user, pas plus, par contre, comme ça fait un bon rm -rf sur la racine de l’arborescence de fichiers “/”, bah ça ne peut supprimer aucun fichier système, par contre tout ce qui est accessible en écriture y passe…

Donc ça implique autant ton dossier personnel situé dans /home, que d’éventuels médias distants (partages réseaux), montés dans /mnt ou /media, avec un accès en écriture…



P’tain, je dois avouer que j’aurais TRÈS méchamment la rage si Steam venait à m’effacer tous mes disques… <img data-src=" />



Y’a deux problèmes à ça.





  • Steam ne fait partie d’aucun dépôt, ce n’est pas un logiciel libre, c’est donc à eux de faire le boulot d’intégration.



  • Y’a encore peu de profils SeLinux pour les applications utilisateurs, car contrairement à un daemon automate, le comportement de l’utilisateur est difficile à rationaliser dans des règles.



    Exemple tu prend Gimp et tu le lance dans Docker il devra quand-même accéder au Home car l’utilisateur veut pouvoir charger/enregistrer des images depuis cet emplacement.


Bug ou code volontaire?


C’est Steamguard qui préfère tout détruire en cas de changement de path douteux.

There is the Gabe way and there is the wrong way.


Code volontaire !!

Le Mossad a infiltré Valve dans le but de supprimer les données de tout les djihadistes anti-imperialiste Américain (ce que représente Micro$$$oft) adeptes de Call of Duty








GentooUser a écrit :



Y’a deux problèmes à ça.





  • Steam ne fait partie d’aucun dépôt, ce n’est pas un logiciel libre, c’est donc à eux de faire le boulot d’intégration.



  • Y’a encore peu de profils SeLinux pour les applications utilisateurs, car contrairement à un daemon automate, le comportement de l’utilisateur est difficile à rationaliser dans des règles.



    Exemple tu prend Gimp et tu le lance dans Docker il devra quand-même accéder au Home car l’utilisateur veut pouvoir charger/enregistrer des images depuis cet emplacement.





    1 - Si tu obliges à la présence de sandboxing dans les paquets ils seront obliger de le mettre.

    2 - Le comportement de l’application est en général relativement simple à prévoir.

    3 - Oui tu peux avoir accès au home mais pas a tout et de plus tu dois pouvoir limiter l’accès a certaines actions (enregistrer, charger un fichier par exemple)



    Tout ca n’est pas nouveau est on a quand même un gros feedback avec les usages sur mobiles. je pense qu’il manque juste une implémentation adapté sur les distributions Desktop.









dematbreizh a écrit :



rien de tel qu’un bon

chmod 777 /*

chmod 777 //

chmod 777 ///*



:p







&nbsp;Pourquoi pas un :

&nbsp;

&nbsp;# chmod -R 777 /

&nbsp;

Plus court et plus efficace :)



Bug, catégorie lamentable.



On peut trouver facilement le script, et là on voit un commentaire qui dit que si telle variable est une chaine vide ça va faire mal, et qui ne teste pas cette variable.

(Et comme c’est du shell, une variable vide est vite arrivée).



&nbsp;


oh mon dieu !

Ces videos complotistes sur Youtube disaient donc vrai !?

^^








dematbreizh a écrit :



rien de tel qu’un bon

chmod 777 /*

chmod 777 //

chmod 777 ///*



:p





Aussi efficace qu’un coup de fusil à pompe dans l’oeil <img data-src=" />



Merci de le rappeler <img data-src=" /> J’ai eu ce bug il y a moins d’un an, après un changement de DD et de réinstall Windows et j’ai voulu changer l’emplacement de Steam.

Après tentative de “ réparation” de Steam, tout le contenu du second DD avait disparu, hormis le dossier Steam et quelques fichiers…Je n’avais rien trouvé sur le web à ce moment, et je n’en ai pas fait tout un foin, juste perdu 3 ou 4 h à restaurer un backup du DD…



Après faut voir le bon coté des choses, au moins les jeux sur le steam cloud sont sauvés&nbsp;<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />


Ce sont vraiment des bits chez Steam.








FeathersMG a écrit :



Je dirai plutôt “La preuve que chez Valve on ne sait pas faire un script shell”. Ça n’a rien à voir avec Linux, on peut très bien effacer toutes les données d’un disque Windows avec un script pourri aussi.

Heureusement, le patch d’urgence est rapide à mettre en place : ouvrir le script, mettre # devant le rm -rf en question et sauver le script.





Je suis à peu près certains que le même bug sur windows donnerais les commentaires habituels des libristes anti MS comme quoi windows c’est organisé comme de la merde, sur linux les des droits d’admin empêcherais le logiciel de faire tout et n’importequoi etc, etc…



chmod -R 000 /*



Beaucoup plus marrant <img data-src=" />


Remarquez, si les desktops étaient organisés comme les serveurs, Steam se lançerait avec un utilisateur “Steam” et des droits réduits, et il ne pourrait casser que ses propres fichiers. Mais bon, c’est chiant à gérer.



En attendant, j’ai à la maison un Linux, avec un Steam dans un dossier qui n’est pas le dossier par défaut, et je <img data-src=" /><img data-src=" />


Ah mais c’est le cas, Windows est déjà un foutoir monstre avec ses 36 copies de librairies dans de multiples dossiers.

Après Linux, c’est clairement pas aussi user friendly que ça le devrait, le système en soit l’est désormais, mais ça manque d’outils graphiques tiers qui foisonnent pour tout et n’importe quoi sous Windows (et c’est normal, vu le nombre de gens l’utilisant).

Assez récemment, je pense que l’arrêt du développement de certains projets (Ubuntu Tweak et XCFA entre autres) a laissé un gros vide… Sous Windows il y aurait forcément eu des gens pour les reprendre, sous Linux par contre, c’est plus dur…


La solution ce n’est pas d’installer Steam ailleurs je pense, d’autant plus qu’on peut créer des liens symboliques pour le dossier SteamApps contenant tous les jeux, ou même indiquer à Steam lui même de nouveaux dossier ou récupérer/installer des jeux.




si la variable « STEAMROOT » est vide pour une raison ou pour un autre, cette commande se transformerait en « rm -rf “/”* » qui a pour effet de tout effacer, un peu à la manière d’un « Format c: »





«Un peu» à la manière, moui…



Le client Steam ne s’exécute qu’avec les droits d’un utilisateur, la commande «rm -f /*» ne pourra donc pas supprimer tous les fichiers sur le disque, seulement les fichiers modifiables par cet utilisateur. En gros ça supprimera tout son répertoire personnel, mais pas les données des autres utilisateurs, ni aucun fichier système.



On est donc bien loin du formatage d’une partition. Je comprends que pour des néophytes on a envie d’expliquer ça comme ça pour simplifier, mais sur un site high-tech comme NextINpact je trouve ça dommage de faire ce genre de raccourci, car c’est très trompeur.



Quoi qu’il en soit, le coup de la variable qui peut être vide, ils n’y ont pas pensé chez Valve… C’est quand même une erreur de débutant, ils ont un peu fait leurs boulets sur ce coup-là.


Certaines applis ne savent pas ce qu’est un lien symbolique, j’avais jugé plus sûr de changer carrément le dossier d’installation. Pauvre fou que j’étais&nbsp; <img data-src=" />.








chichillus a écrit :



En attendant, j’ai à la maison un Linux, avec un Steam dans un dossier qui n’est pas le dossier par défaut, et je <img data-src=" /><img data-src=" />





Tu peux toujours modifier le script pour corriger le problème. Cela ne doit pas être très dure.



Puis faire un reboot ?


C’est plutôt rare que les liens symboliques posent des problèmes, généralement ils permettent surtout de gruger et tweaker la destination de dossiers au nez et à la barbe d’applications, justement.



Exemple typique, Steam est super CHIANT avec la création d’un dossier SteamAPPS sur des partitions NTFS ou réseau, il t’emmerde pour un oui ou un non en te disant que tu doit avoir les droits d’exécution là ou est créé ledit dossier… En créant un dossier caché .MonDossier dans le home, en l’indiquant à Steam, puis en le créant sur le disque NTFS/réseau et en faisant un lien symbolique vers .MonDossier, plus de problèmes.

Avant on pouvait directement modifier en dur dans un fichier de configuration de Steam les dossiers à prendre en compte, mais ça ne fonctionne plus depuis quelques semaines… :(


C’est ce que je ferai en rentrant.



Mais ça fait drôle de découvrir une bombe à retardement sur son PC. Surtout que Linux sécurisé blabla toussa. Ça m’apprendra à installer n’importe quoi <img data-src=" />








seb2411 a écrit :



1 - Si tu obliges à la présence de sandboxing dans les paquets ils seront obliger de le mettre.





Ça gène un peu la liberté de l’utilisateur ça.



2 - Le comportement de l’application est en général relativement simple à prévoir.



Pour steam oui, ça représente pas un gros boulot, mais je parlais en général.

&nbsp;



3 - Oui tu peux avoir accès au home mais pas a tout et de plus tu dois pouvoir limiter l’accès a certaines actions (enregistrer, charger un fichier par exemple)



Le nombre d’utilisateurs qui utilisent la boite de dialogue ouvrir/eregistrer pour créer des dossier, supprimer des fichiers…



Tout ca n’est pas nouveau est on a quand même un gros feedback avec les usages sur mobiles. je pense qu’il manque juste une implémentation adapté sur les distributions Desktop.



&nbsp;Surtout pas comme sur le mobile, mais on peut imaginer des choses oui. Genre confier la boite de dialogue ouvrir/enregistrer à une bibliothèque privilégiée et en dehors de ces opérations le logiciel ne peut accéder qu’à ses propres fichiers. &lt;troll&gt;Et pourquoi pas confier ce genre de choses à systemd ?&lt;/troll&gt;









GentooUser a écrit :



Ça gène un peu la liberté de l’utilisateur ça.




2 - Le comportement de l'application est en général relativement simple à prévoir.       






Pour steam oui, ça représente pas un gros boulot, mais je parlais en général.      

&nbsp;






 3 - Oui tu peux avoir accès au home mais pas a tout et de plus tu dois pouvoir limiter l’accès a certaines actions (enregistrer, charger un fichier par exemple)       






Le nombre d'utilisateurs qui utilisent la boite de dialogue ouvrir/eregistrer pour créer des dossier, supprimer des fichiers...      






 Tout ca n'est pas nouveau est on a quand même un gros feedback avec les usages sur mobiles. je pense qu'il manque juste une implémentation adapté sur les distributions Desktop.     





&nbsp;Surtout pas comme sur le mobile, mais on peut imaginer des choses oui. Genre confier la boite de dialogue ouvrir/enregistrer à une bibliothèque privilégiée et en dehors de ces opérations le logiciel ne peut accéder qu’à ses propres fichiers. Et pourquoi pas confier ce genre de choses à systemd ?





De toute manière la boite de dialogue d’ouverture/enregistrement des fichiers et déjà sous la responsabilité de l’environnement de Bureau. Du coup il faudra voir. Ubuntu bosse dessus aussi, on verra donc comment ils vont gérer tout ça (notamment les cas complexes). Gnome commence aussi a se soucier du problème.



STEAMROOT = “~/.steamroot”



“What the fuck”



&nbsp;if \(STEAMROOT &lt;&gt; null&nbsp; then rm -rf \)STEAMROOT/*

&nbsp;


Moi de toute façon avec linux j’ai l’habitude de faire un formatage de la partition depuis windows <img data-src=" />


Comme dit plus haut, les fichiers modifiables par l’utilisateur ne concernent pas toujours que le home. Pour peu qu’il y ait un media externe, ou interne, qui est accessible en écriture, genre NTFS, voir simplement un ext4 accessible en écriture à tous, et il y passe intégralement. Sympa de voir tous ses NAS d’un coup formatés, non?


je vois que Valve a gardé de bonne vieille habitudes =)

remember sur half life avec le sierra utilities. Lors de la désinstall d’half life y avait tout le repertoire parent qui était effacé également =) celui qui mettait son jeu dans program files pouvait rager sec XD.


Encore du code pondu par un informaticien incompétent.








Crysalide a écrit :



Encore du code pondu par un informaticien développeur incompétent.





<img data-src=" />





Valve a envoyé un communiqué de presse:





“We are going to fix this feature and replace it by&nbsp; shred /dev/sda3”


Ici on parle ce changement manuel de répertoire, il existe donc une fonction automatique intégré à steam ?

Si oui ces utilisateurs ont été punis par où ils ont péché : “LA BIDOUILLE” encore plus dangereuse sous windows



mouahahahah -&gt;[]


Rho tous ces trolls ! on se croirait dans une forêt d’heroic-fantasy <img data-src=" />



Donc a priori Keyvin, en déplaçant un dossier d’installation sur un point d’accès différent, il aurait invalidé malgré lui une variable.



mais quand même, écrire un rm -f $var/ dans un script, faut quand même être certain que la variable en faudra jamais null.



Comme l’aurait dit mon professeur : “il vous manque un test unitaire ! 220<img data-src=" />








athlon64 a écrit :



Encore du code pondu par un geek nerd.

<img data-src=" />




mais c’est quoi ce nouveau système de commentaires tout buggé?!? On n’arrive rien à faire correctement, c’est n’importe nawak!!!



Rendez-nous les balises!&nbsp;<img data-src=" />


en haut des commentaires clique sur “Options” et tu pourras les réactiver <img data-src=" />








athlon64 a écrit :



en haut des commentaires clique sur “Options” et tu pourras les réactiver <img data-src=" />





<img data-src=" />



Or, si la variable&nbsp;« STEAMROOT&nbsp;» est vide pour une raison ou pour un autre, cette commande&nbsp;se transformerait en&nbsp;&nbsp;« rm -rf “/”* » qui a pour effet de tout effacer, un peu à la manière d’un&nbsp;« Format c: »



Holly shit!


juste une variable vide .. ça arrive <img data-src=" />


C’est bizarre ce bug. J’ai personnellement déplacé mon Steam de /home/utilisateur/.steam vers /pub/steam et création d’un lien symbolique et je n’ai pas eu de problème. Quant aux trolls qui persiflent sur l’injouabilité du pingouin, ils devraient regarder la différence entre Borderlands2 sous Linux et sous Windows. L’opengl est bien plus joli que DX9.








gokudomatic a écrit :



Comme dit plus haut, les fichiers modifiables par l’utilisateur ne concernent pas toujours que le home. Pour peu qu’il y ait un media externe, ou interne, qui est accessible en écriture, genre NTFS, voir simplement un ext4 accessible en écriture à tous, et il y passe intégralement. Sympa de voir tous ses NAS d’un coup formatés, non?







Oui tout à fait, ça supprime tous les fichiers auxquels l’utilisateur a accès en écriture. Le home bien sûr, et comme tu le dis, les medias externes s’il y en a.



Je persiste à dire que c’est très différent d’un formatage <img data-src=" />









Konrad a écrit :



Oui tout à fait, ça supprime tous les fichiers auxquels l’utilisateur a accès en écriture. Le home bien sûr, et comme tu le dis, les medias externes s’il y en a.&nbsp;





Hummm… il me semble que ça supprime plus que ça:&nbsp;

Ca supprime également tous les fichiers présents dans des répertoires dont il a les droits en écriture, même si les fichiers sont protégés en écriture (j’ai d’ailleurs déjà utilisé cette “feature” pour “modifier” un fichier sur lequel je n’avais aucun droit…)&nbsp;



Donc dans un répertoire commun à plusieurs utilisateurs, tous les fichiers seront supprimés, même si l’utilisateur propriétaire a été prudent.



Lennart Poettering, l’auteur de systemd, avait sorti un billet de blog il y a quelques temps, pour expliquer comment il voyait le futur de la distribution d’applications sous Linux, et le sandboxing de ces dernières.



Par la suite, Allan Day, qui s’occupe de l’ergonomie de l’environnement de bureau GNOME, en a publié deux autres (ici et ) pour expliquer sa vision de l’intégration de toutes ces technologies, et comment elles seraient exposées à l’utilisateur.


tu peux. C’est effectivement très différent d’un formatage puisque ça ne fait qu’enlever des pointeurs de fichiers non système. Mais ça n’en fait pas moins mal au <img data-src=" />, surtout si par exemple, la partition windows était accessible en écriture. Parce que cette partition là, elle est bonne pour être reformatée dans tous les cas.


Oui. Et son NAS qui se vide. Ca fait mal aussi… J’en tremble rien que d’y penser. Juste pour un répertoire…


Tellement vrai, parce que ça peut être pire:




  • Formatage =&gt; 1/ (re)install 2/ prend le disque de sauvagerde, restaure

  • Avec ce bug, les gens qui se plaignent sont ceux dont le ou les disques de sauvegarde étaient montés

    &nbsp;=&gt; plus de données à restaurer.



    Moralité:

    Gros bug de steam, mais penser à rajouter quelques lignes dans le manuel des «bonnes pratiques» concernant le traitement des disques de sauvegarde.


Euh, là ce n’est même plus un bug, c’est une erreur flagrante d’écriture. Même moi qui ne suis pas développeur de formation (ou est-ce justement pour ça ?) quand je manipule des commandes dangereuses comme ça je mets des gardes-fous, le strict minimum étant justement de s’assurer du chemin cible !!



Ne pas avoir prévu ce type de situation ça craint. Vraiment…








Okki a écrit :



Lennart Poettering, l’auteur de systemd, avait sorti un billet de blog il y a quelques temps, pour expliquer comment il voyait le futur de la distribution d’applications sous Linux, et le sandboxing de ces dernières.



Par la suite, Allan Day, qui s’occupe de l’ergonomie de l’environnement de bureau GNOME, en a publié deux autres (ici et ) pour expliquer sa vision de l’intégration de toutes ces technologies, et comment elles seraient exposées à l’utilisateur.





Yep c’est ce que j’avais lu. Par contre je sais pas ou ça en est cote Gnome et si ils ont avancé ou pas ?



je pense surtout au fait que la simple commande “rm -rf /” est tellement à portée de main et qu’on ne peut rien faire avec des moyens raisonnables de l’en empêcher, que le moindre script-kiddie qui arrive à convaincre un linuxien d’executer son programme peut executer ça. Va falloir que canonical nous sorte une version sa version personnelle du rm qui pose en tous cas une fois la question si on veut supprimer lorsqu’on met -rf en option.

Oui, je dis canonical, parce que tous les autres acteurs du libre refuseraient un truc pareil s’il n’est pas agréé par tout le monde.








gokudomatic a écrit :



je pense surtout au fait que la simple commande “rm -rf /” est tellement à portée de main et qu’on ne peut rien faire avec des moyens raisonnables de l’en empêcher, que le moindre script-kiddie qui arrive à convaincre un linuxien d’executer son programme peut executer ça. Va falloir que canonical nous sorte une version sa version personnelle du rm qui pose en tous cas une fois la question si on veut supprimer lorsqu’on met -rf en option.

Oui, je dis canonical, parce que tous les autres acteurs du libre refuseraient un truc pareil s’il n’est pas agréé par tout le monde.





Comme dit plus haut, ils bossent déjà dessus via des applications sandboxés. Ca va arriver avec Unity 8.



if [&nbsp; -n “\(STEAMROOT" ]

then rm -rf "\)
STEAMROOT/”*

fi


Il faut tester si ça n’est pas $STEAMROOT != “/home” ou “/media”


Jamais eu de souci.

Vu le nombre limité de cas, on est pas à l’abri de l’utilisateur full root qui installe ses jeux dans la racine.








Konrad a écrit :



Je persiste à dire que c’est très différent d’un formatage <img data-src=" />





Oui, c’est différent. format C: ne fonctionnera pas avec le système lancé il me semble.







gokudomatic a écrit :



Va falloir que canonical nous sorte une version sa version personnelle du rm qui pose en tous cas une fois la question si on veut supprimer lorsqu’on met -rf en option.





Tu peux aussi mettre dans /bin ton rm qui demande confirmation avant d’appeler le vrai rm si on utilise la combinaison -rf



Autre question: si on enlève le droit “r” d’un répertoire, en laissant le “x”, est-ce que l’utilisateur peut toujours aller dans le répertoire mais uniquement s’il connaît le nom des fichiers? Dans ce cas on peut protéger en permettant de faire un “cd /home/compte” mais en interdisant de faire “ls /home” (je le fais parfois sous Windows)



Je partai du principe que $STEAMROOT est un sous-répertoire créé par un script d’installation de Steam, et non un répertoire arbitraire indiqué par l’utilisateur, sinon la commande n’a pas lieu d’être, et il faut effacer chaque fichier installé.








brice.wernet a écrit :



[question sur les droits des répertoires]





Oui, ça marche comme ça.



Pour reprendre l’exemple, on peut aussi lire le fichier /home/text-file s’il existe.



Tu as la même chose sous windows hein, les commandes de scripts sont puissantes et puis c’est tout… les scripts sont fait pour automatiser, pas pour restreindre l’opérateur à rester devant son écran <img data-src=" />



Par contre il y aussi des options pour rm genre –preserve-root

fail to operate recursively on ‘/’



Ca peut déjà limiter la casse…


Je comprends surtout pas comment une désinstallation peut être assimilée à un rm -rf /path/to/folder

C’est juste débile de faire la supposition que tous les fichiers à l’intérieur du dossier d’installation sont des fichiers, primo qui appartiennent à l’application, deuxio que l’utilisateur ne veut pas garder… (sauvegardes de jeux, fichiers de jeux, fichiers de configs…)


Si tu te contente juste de vérifier que la variable n’est pas vide, tu peux avoir tout autant de problèmes. Personnellement, j’utiliserai plutôt -dO, pour m’assurer qu’il s’agit bien d’un répertoire, bel et bien présent, et que le propriétaire de ce dernier est bien le même que celui qui exécute le script.


Il y a quelques mois, Gaming on Linux avait publié un article sur les jeux qui s’installaient n’importe où et foutaient la merde dans le répertoire de l’utilisateur.



Alors que normalement, il existe une norme à respecter quand à l’emplacement des fichiers. Par exemple, les fichiers de configuration du jeu devraient aller dans \(XDG\_CONFIG\_HOME (ce qui correspond par défaut à \)HOME/.config). Les sauvegardes devraient aller dans \(XDG\_DATA\_HOME (ce qui correspond à \)HOME/.local/share). Et ainsi de suite.



Ce qui permet de faire aisément la distinction entre toutes ces données, et lors d’une demande de désinstallation, de pouvoir laisser le choix à l’utilisateur de ce qu’il souhaite garder. Ça rend également les backups beaucoup plus simples.



Malheureusement, les éditeurs n’en ont rien à foutre, et ça va finir comme sous Windows…








Xaelias a écrit :



Je comprends surtout pas comment une désinstallation peut être assimilée à un rm -rf /path/to/folder

C’est juste débile de faire la supposition que tous les fichiers à l’intérieur du dossier d’installation sont des fichiers, primo qui appartiennent à l’application, deuxio que l’utilisateur ne veut pas garder… (sauvegardes de jeux, fichiers de jeux, fichiers de configs…)





Les données sont sauvegardées(synchronisées) sur le cloud Steam.<img data-src=" />



Il n’y a pas que les éditeurs qui s’en foutent, les utilisateur aussi, manifestement. C’est quoi l’intérêt de Steam sous Linux, si ça implique d’utiliser des pilotes propriétaires et d’installer des jeux dont on sait pertinemment qu’ils ne respecteront pas les conventions du système (vu qu’ils ne sont pas inclus dans la distribution).



Autant une Steambox ça peut avoir du sens, vu que c’est un système autonome, autant Steam dans une distribution Linux c’était foireux dès le départ, à mon avis.


omg, des users qui ont pas tous leurs fichiers sur une seule et unique partition C: ont déplacé des répertoires…

scary en effet comme indiqué par le commentaire du dev valve sur PC World.



Je suis content de pas avoir lancé mon client steam depuis des mois.



Je plains ceux à qui cette mésaventure est arrivée, tu veux jouer à un jeu vidéo, tu oublies le reste parce que de toute façon, le jeu dégage le reste. <img data-src=" /> <img data-src=" />


Perso, parfois, dans le doute, je contrôle même ce qui ne doit pas arriver.


Vous oubliez un léger détail dans toute cette histoire.

Vous avez beau avoir les droits sur ces fichiers, il y a selinux qui veille au grain.


hum… oui, il y a les mêmes commandes sous windows. Mais les installations/désinstallations sous windows n’utilisent généralement pas des scripts de commandes CMD/BAT/powershell.



Les “setup” sont généralement des programmes tout-fait (NSIS , Inno, …) qui sont personnalisés/scriptés. Et ces programmes sont suffisamment bien fait pour ne pas faire un DEL /S /Q <img data-src=" />


Sinon, créez un utilisateur spécial pour steam pour éviter toute mésaventure, comme vous le feriez pour un serveur (j’espère que vous le faites <img data-src=" />)








127.0.0.1 a écrit :



hum… oui, il y a les mêmes commandes sous windows. Mais les installations/désinstallations sous windows n’utilisent généralement pas des scripts de commandes CMD/BAT/powershell.



Les “setup” sont généralement des programmes tout-fait (NSIS , Inno, …) qui sont personnalisés/scriptés. Et ces programmes sont suffisamment bien fait pour ne pas faire un DEL /S /Q <img data-src=" />





Rien n’empêche steam de faire de même sur Linux, en maintenant un canal de distribution.



Christian Schaller vient de publier un billet de blog où il décrit toutes les nouveautés de Fedora 22 (Wayland devrait être pleinement fonctionnel et proposé par défaut, de grosses améliorations sur la consommation d’énergie et la durée de vie des batteries sont également attendues…)



Puis il traite également du cas des applications sandboxées (voir le paragraphe Application bundles). Apparemment, ça ne sera pas prêt pour Fedora 22, mais ça sera tout de même proposé en tant que preview technologique. Dès aujourd’hui, on peut d’ores et déjà récupérer des environnements GNOME 3.14 et 3.16 (version en cours de développement) par ce biais, et utiliser des applications sandboxées de démonstration (gedit, builder, puis des trucs plus anecdotiques pour tester le fonctionnement d’OpenGL ou de l’audio au sein d’une sandbox).








Okki a écrit :



Christian Schaller vient de publier un billet de blog où il décrit toutes les nouveautés de Fedora 22 (Wayland devrait être pleinement fonctionnel et proposé par défaut, de grosses améliorations sur la consommation d’énergie et la durée de vie des batteries sont également attendues…)



Puis il traite également du cas des applications sandboxées (voir le paragraphe Application bundles). Apparemment, ça ne sera pas prêt pour Fedora 22, mais ça sera tout de même proposé en tant que preview technologique. Dès aujourd’hui, on peut d’ores et déjà récupérer des environnements GNOME 3.14 et 3.16 (version en cours de développement) par ce biais, et utiliser des applications sandboxées de démonstration (gedit, builder, puis des trucs plus anecdotiques pour tester le fonctionnement d’OpenGL ou de l’audio au sein d’une sandbox).





Cool. Bonne nouvelle alors.



Norme qui devrait d’ailleurs être revue pour proposer des noms plus parlants pour l’utilisateur, au vu de la puissance actuelle, pour l’utilisateur moyens les noms de répertoires/fichiers en trois lettres n’apportent plus de gain significatif en performances.

Et local/share, pour des sauvegardes, c’est moche (rarement vu moins parlant pour l’utilisateur).



Sur le principe ceci dit 100% d’accord avec toi.







Xaelias a écrit :



Je comprends surtout pas comment une désinstallation peut être assimilée à un rm -rf /path/to/folder



C’est juste débile de faire la supposition que tous les fichiers à

l’intérieur du dossier d’installation sont des fichiers, primo qui

appartiennent à l’application, deuxio que l’utilisateur ne veut pas

garder… (sauvegardes de jeux, fichiers de jeux, fichiers de

configs…)







+10 Également c’est complètement stupide vu que par défaut Steam installe ses jeux dans un sous-répertoire, et tous les jeux n’ont pas la bonne pratique de placer leurs sauvegardes en dehors de leur répertoire d’install (et pour ceux qui les placent dans le Home de Windows, c’est presque autant le bordel mais c’est un autre sujet). Sans compter les configs, mods, maps etc…





psn00ps a écrit :



Les données sont sauvegardées(synchronisées) sur le cloud Steam.<img data-src=" />



Pour une partie des jeux oui (30% ? 40% ?) sur la plupart des jeux gourmands en espace disque pour les sauvegardes ce nest pas vrai (Civ 5 étant une exception astucieuse qui confirme la règle car il ne sauvegarde que les 3 ou 4 saves les plus récentes si ma mémoire est bonne).



yes mon capitaine, mais aussi il faut Toujours initialiser une variable (même avec une données par défauts)








Okki a écrit :



Christian Schaller vient de publier un billet de blog où il décrit toutes les nouveautés de Fedora 22 (Wayland devrait être pleinement fonctionnel et proposé par défaut, de grosses améliorations sur la consommation d’énergie et la durée de vie des batteries sont également attendues…)



Puis il traite également du cas des applications sandboxées (voir le paragraphe Application bundles). Apparemment, ça ne sera pas prêt pour Fedora 22, mais ça sera tout de même proposé en tant que preview technologique. Dès aujourd’hui, on peut d’ores et déjà récupérer des environnements GNOME 3.14 et 3.16 (version en cours de développement) par ce biais, et utiliser des applications sandboxées de démonstration (gedit, builder, puis des trucs plus anecdotiques pour tester le fonctionnement d’OpenGL ou de l’audio au sein d’une sandbox).







Merci pour ces infos, l’arrivée de sandboxes dans les distribs est une bonne nouvelle <img data-src=" />



Je comprend mal l’intêret des sandboxes dans Linux, compte tenu de la réactivité des devs et d’autres éléments comme la gestion des droits sensiblement plus solide qu’un Windows, etc. Mais bon, c’est toujours bon à prendre.



En tout cas, je constate que Linux devient de plus en plus “normal” à mesure que l’on trouve ce type de bug chelou spécial Windows en général <img data-src=" /> Bientôt les linuxiens ne seront plus une classe à part de la société <img data-src=" />


Pour un système uniquement composé de logiciels libres, c’est effectivement un peu moins intéressant. Quand il s’agit de drivers ou de logiciels libres, la communauté ou les équipes dédiées des différentes distributions commerciales peuvent corriger les bugs, les failles de sécurité, s’assurer que ça ne fait rien dans ton dos, comme envoyer des informations te concernant à un éditeur tiers…



Par contre, dès que tu te met à installer des logiciels propriétaires, la communauté est tout de suite écartée, et tu dois avoir une confiance aveugle dans l’éditeur. Nous n’avons aucun moyen de corriger ou d’améliorer quoi que ce soit, tout comme nous n’avons plus aucun moyen de savoir ce que fait réellement le logiciel.



Par conséquent, puisque nous ne pouvons pas avoir confiance, on enferme le logiciel dans une boîte, et on contrôle beaucoup plus finalement ce qu’il a le droit de faire, à quoi il peut accéder, et ce qui peut en sortir.



Ensuite, au delà des questions de sécurité, il y a la toute bête question de la distribution des logiciels par les éditeurs. Sous Windows, un éditeur choisi quelle version minimum de Windows il souhaite supporter, il compile son logiciel en fonction, et ça tournera sur toutes les versions suivantes. S’il vise Vista, ça tournera également sous Windows 7 et 8.



Tandis que sous Linux, de part l’extrême liberté qu’on a d’assembler différents composants pour créer une distribution, que ce soit les versions des logiciels et des bibliothèques qui diffèrent, le système d’init qui peut changer lui aussi (upstart sous Ubuntu, systemd sur les autres), le serveur d’affichage (actuellement X.org pour tout le monde, mais bientôt Mir pour Ubuntu, et Wayland pour les autres), que ça devient compliqué pour un éditeur de logiciels propriétaire de supporter plusieurs distributions.



Dans le cas de logiciels libres, chaque distribution fait elle-même le boulot qui la concerne, mais pour un logiciel propriétaire, c’est à l’éditeur de se démerder.



Donc là, l’idée, ça serait de continuer à avoir des distributions telles qu’on les connaît aujourd’hui, avec les systèmes de packages habituels (DEB, RPM…), tout en pouvant, dans la foulée, installer des conteneurs fournis par différents acteurs. Par exemple, GNOME pourrait fournir un conteneur contenant une version complète de chacune de ses versions. Un éditeur commercial qui développerait une application pour cet environnement, proposait lui aussi un conteneur avec son application et tout ce dont il a besoin, en indiquant pour quelle version de GNOME son application est prévue.



Au final, en tant qu’utilisateur, même si t’as une Debian avec une version de GNOME beaucoup plus vieille que ce qui est nécessaire pour ce programme, tu récupères les deux conteneurs, tout en pouvant ainsi utiliser l’application sans problème.



Ça simplifie la vie de tout le monde, tout en améliorant la sécurité.



Par contre, n’étant pas développeur sur ces questions et n’ayant suivi tout ça que de loin, j’ai peut être mal interprété certains points, même si ça doit être ok pour l’idée générale.








bonizuka a écrit :



chmod -R 000 /*



Beaucoup plus marrant <img data-src=" />





Sadique !<img data-src=" />

&nbsp;