Quand le client Steam sur Linux efface toutes vos données
Le rm -f est à manier avec parcimonie
Le 19 janvier 2015 à 09h31
3 min
Logiciel
Logiciel
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.
Quand le client Steam sur Linux efface toutes vos données
-
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é
Commentaires (103)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 19/01/2015 à 15h28
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…
Le 19/01/2015 à 15h38
Le 19/01/2015 à 15h52
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.
Le 19/01/2015 à 15h56
Le 19/01/2015 à 16h38
if [ -n “\(STEAMROOT" ]
then rm -rf "\)STEAMROOT/”*
fi
Le 19/01/2015 à 16h51
Il faut tester si ça n’est pas $STEAMROOT != “/home” ou “/media”
Le 19/01/2015 à 16h56
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.
Le 19/01/2015 à 17h19
Le 19/01/2015 à 17h34
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é.
Le 19/01/2015 à 17h53
Le 19/01/2015 à 17h58
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…
Le 19/01/2015 à 18h12
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…)
Le 19/01/2015 à 18h25
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.
Le 19/01/2015 à 18h41
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…
Le 19/01/2015 à 18h49
Le 19/01/2015 à 18h56
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.
Le 19/01/2015 à 19h41
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.
Le 19/01/2015 à 22h21
Perso, parfois, dans le doute, je contrôle même ce qui ne doit pas arriver.
Le 19/01/2015 à 22h22
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.
Le 19/01/2015 à 22h24
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
Le 19/01/2015 à 23h08
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
" />)
Le 19/01/2015 à 23h11
Le 20/01/2015 à 02h23
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).
Le 20/01/2015 à 08h10
Le 20/01/2015 à 09h27
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.
Le 20/01/2015 à 09h53
yes mon capitaine, mais aussi il faut Toujours initialiser une variable (même avec une données par défauts)
Le 20/01/2015 à 17h46
Le 20/01/2015 à 23h31
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.
" /> Bientôt les linuxiens ne seront plus une classe à part de la société 
" />
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
Le 21/01/2015 à 00h34
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.
Le 21/01/2015 à 10h14
Le 19/01/2015 à 09h33
Outch méchant le bug.
Le 19/01/2015 à 09h35
Vivement les applications sandboxe sous Linux.
Le 19/01/2015 à 09h36
Le 19/01/2015 à 09h37
Encore une fois la preuve que Linux est beaucoup plus dangereux que Windows 
" />
Le 19/01/2015 à 09h44
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.
Le 19/01/2015 à 09h47
la preuve que linux n’est pas fait pour jouer.
Le 19/01/2015 à 09h48
Le 19/01/2015 à 09h49
En effet, un utilisateur sous le pseudonyme de Keyvin détaille sa mésaventure
Ça ressemble à une blague-troll sur JV.com
Le 19/01/2015 à 09h49
C’est encore du teasing pour HL3 ?
" />
Le 19/01/2015 à 09h50
[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…
" /> [/HS]
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.
Concernant la news, ça veut dire que Steam a un accès root sur tout le système ?
Le 19/01/2015 à 09h51
attention, tu devrais tailler ta barbe, si elle commence à descendre plus bas que ton cou, c’est mauvais signe.
Le 19/01/2015 à 09h51
Le 19/01/2015 à 12h20
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…
Le 19/01/2015 à 12h21
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.
Le 19/01/2015 à 12h26
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à.
Le 19/01/2015 à 12h29
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 
" />.
Le 19/01/2015 à 12h39
Le 19/01/2015 à 12h49
Puis faire un reboot ?
Le 19/01/2015 à 12h52
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… :(
Le 19/01/2015 à 12h53
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
Le 19/01/2015 à 12h57
Le 19/01/2015 à 13h03
Le 19/01/2015 à 13h29
STEAMROOT = “~/.steamroot”
…
“What the fuck”
…
if \(STEAMROOT <> null then rm -rf \)STEAMROOT/*
Le 19/01/2015 à 13h36
Moi de toute façon avec linux j’ai l’habitude de faire un formatage de la partition depuis windows
" />
Le 19/01/2015 à 13h41
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?
Le 19/01/2015 à 13h43
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.
Le 19/01/2015 à 13h49
Encore du code pondu par un informaticien incompétent.
Le 19/01/2015 à 13h52
Le 19/01/2015 à 10h41
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.
Le 19/01/2015 à 10h45
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
Le 19/01/2015 à 10h48
Le 19/01/2015 à 10h51
Le 19/01/2015 à 10h57
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).
Le 19/01/2015 à 11h07
oh mon dieu !
Ces videos complotistes sur Youtube disaient donc vrai !?
^^
Le 19/01/2015 à 11h24
Le 19/01/2015 à 11h24
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…
Le 19/01/2015 à 11h38
Après faut voir le bon coté des choses, au moins les jeux sur le steam cloud sont sauvés 
" />
" />
" />
" />
" />
" />
Le 19/01/2015 à 11h57
Ce sont vraiment des bits chez Steam.
Le 19/01/2015 à 12h05
Le 19/01/2015 à 12h12
chmod -R 000 /*
" />
Beaucoup plus marrant
Le 19/01/2015 à 12h18
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
Le 19/01/2015 à 13h54
Valve a envoyé un communiqué de presse:
“We are going to fix this feature and replace it by shred /dev/sda3”
Le 19/01/2015 à 13h55
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 ->[]
Le 19/01/2015 à 14h15
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 ”
Le 19/01/2015 à 14h17
Le 19/01/2015 à 14h22
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!
Le 19/01/2015 à 14h23
en haut des commentaires clique sur “Options” et tu pourras les réactiver
" />
Le 19/01/2015 à 14h33
Le 19/01/2015 à 14h53
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!
Le 19/01/2015 à 15h01
juste une variable vide .. ça arrive
" />
Le 19/01/2015 à 15h05
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.
Le 19/01/2015 à 15h07
Le 19/01/2015 à 15h17
Le 19/01/2015 à 15h17
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.
Le 19/01/2015 à 15h17
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.
Le 19/01/2015 à 15h18
Oui. Et son NAS qui se vide. Ca fait mal aussi… J’en tremble rien que d’y penser. Juste pour un répertoire…
Le 19/01/2015 à 15h19
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.
Le 19/01/2015 à 09h52
rm -rf “\(STEAMROOT/"* could be evaluated as rm -rf "/"* if \)STEAMROOT is empty.
Ouh que c’est moche
Le 19/01/2015 à 09h53
Le 19/01/2015 à 09h54
Le 19/01/2015 à 09h55
Moi je dirais : “la preuve que les scripts bash sont le mal”
Le 19/01/2015 à 09h55
Le 19/01/2015 à 09h56
Le 19/01/2015 à 09h57
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…
Le 19/01/2015 à 10h01
Le 19/01/2015 à 10h01
Le 19/01/2015 à 10h02
Le 19/01/2015 à 10h11
Le 19/01/2015 à 10h21
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….
Le 19/01/2015 à 10h23
Le 19/01/2015 à 10h25
Le 19/01/2015 à 10h31
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.
Le 19/01/2015 à 10h35
Bug ou code volontaire?