avatar de seb2411

seb2411

INpactien depuis le vendredi 24 octobre 2008

1132 commentaires

20
janvier
2015

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

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.
19
janvier
2015

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

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.
19
janvier
2015

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

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 ?
19
janvier
2015

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


Ç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.
 

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.

 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.
19
janvier
2015

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

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.
19
janvier
2015

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


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...

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.
19
janvier
2015

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

Vivement les applications sandboxe sous Linux.
13
janvier
2015

60 millions d'utilisateurs pour Spotify, dont 15 millions d'abonnés

Le contexte c'est : d’où sors tu ces chiffres ?
13
janvier
2015

60 millions d'utilisateurs pour Spotify, dont 15 millions d'abonnés

Bah tes chiffres ne servent pas a grand chose sans le contexte.