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.
Commentaires (106)
#1
Outch méchant le bug.
#2
Vivement les applications sandboxe sous Linux.
#3
#4
Encore une fois la preuve que Linux est beaucoup plus dangereux que Windows " />
#5
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.
#6
la preuve que linux n’est pas fait pour jouer.
#7
#8
En effet, un utilisateur sous le pseudonyme de Keyvin détaille sa mésaventure
Ça ressemble à une blague-troll sur JV.com " />
#9
C’est encore du teasing pour HL3 ?
" />
#10
[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. " /> [/HS]
Concernant la news, ça veut dire que Steam a un accès root sur tout le système ?
#11
attention, tu devrais tailler ta barbe, si elle commence à descendre plus bas que ton cou, c’est mauvais signe.
#12
#13
rm -rf “\(STEAMROOT/"* could be evaluated as rm -rf "/"* if \)STEAMROOT is empty.
Ouh que c’est moche " />
#14
#15
#16
Moi je dirais : “la preuve que les scripts bash sont le mal”
#17
#18
#19
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…
#20
#21
#22
#23
#24
En effet, un utilisateur sous le pseudonyme de Keyvin détaille sa mésaventure
Ouais mais avec un prénom pareil aussi, il cherche le gars…. " />
#25
#26
#27
Y’a deux problèmes à ça.
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.
#28
Bug ou code volontaire?
#29
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.
#30
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
#31
#32
#33
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).
#34
oh mon dieu !
Ces videos complotistes sur Youtube disaient donc vrai !?
^^
#35
#36
Merci de le rappeler " /> 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…
#37
Après faut voir le bon coté des choses, au moins les jeux sur le steam cloud sont sauvés " />" />" />" />" />" />
#38
Ce sont vraiment des bits chez Steam.
#39
#40
chmod -R 000 /*
Beaucoup plus marrant " />
#41
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 " />" />
#42
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…
#43
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.
#44
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à.
#45
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 " />.
#46
#47
Puis faire un reboot ?
#48
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… :(
#49
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 " />
#50
#51
#52
STEAMROOT = “~/.steamroot”
…
“What the fuck”
…
if \(STEAMROOT <> null then rm -rf \)STEAMROOT/*
#53
Moi de toute façon avec linux j’ai l’habitude de faire un formatage de la partition depuis windows " />
#54
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?
#55
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.
#56
Encore du code pondu par un informaticien incompétent.
#57
#58
Valve a envoyé un communiqué de presse:
“We are going to fix this feature and replace it by shred /dev/sda3”
#59
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 ->[]
#60
Rho tous ces trolls ! on se croirait dans une forêt d’heroic-fantasy " />
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 ! 2⁄20 ” " />
#61
#62
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! " />
#63
en haut des commentaires clique sur “Options” et tu pourras les réactiver " />
#64
#65
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: »
Holly shit!
#66
juste une variable vide .. ça arrive " />
#67
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.
#68
#69
#70
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 là) pour expliquer sa vision de l’intégration de toutes ces technologies, et comment elles seraient exposées à l’utilisateur.
#71
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 " />, 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.
#72
Oui. Et son NAS qui se vide. Ca fait mal aussi… J’en tremble rien que d’y penser. Juste pour un répertoire…
#73
Tellement vrai, parce que ça peut être pire:
=> 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.
#74
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…
#75
#76
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.
#77
#78
if [ -n “\(STEAMROOT" ]
then rm -rf "\)STEAMROOT/”*
fi
#79
Il faut tester si ça n’est pas $STEAMROOT != “/home” ou “/media”
#80
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.
#81
#82
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é.
#83
#84
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 " />
Par contre il y aussi des options pour rm genre –preserve-root
fail to operate recursively on ‘/’
Ca peut déjà limiter la casse…
#85
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…)
#86
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.
#87
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…
#88
#89
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.
#90
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. " /> " />
#91
Perso, parfois, dans le doute, je contrôle même ce qui ne doit pas arriver.
#92
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.
#93
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 " />
#94
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 " />)
#95
#96
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).
#97
#98
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.
#99
yes mon capitaine, mais aussi il faut Toujours initialiser une variable (même avec une données par défauts)
#100
#101
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 " /> Bientôt les linuxiens ne seront plus une classe à part de la société " />
#102
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.
#103