Il y a deux façons d'utiliser les fonctionnalités "bloquées" par la sandbox: soit en configurant les permissions, soit en passant par les portails.
Les permissions de la sandbox sont configurables à deux endroits: coté dev, dans le fichier manifest (le fichier de build de Flatpak); coté utilisateur, c'est actuellement disponible uniquement en ligne de commande.
Je ne sais pas où en est le projet, mais il me semble que la présentation et configuration de ces permissions pour l'utilisateur lambda était un des points prioritaire sur la roadmap du projet.
Par exemple pour le système de fichier, on peut demander à utiliser tout le filesystem, le répertoire $HOME, ou bien un dossier avec un path précis. Le comportement par défaut étant d'avoir seulement quelques dossiers en écriture en utilisant la norme xdg-user-dirs.
Les portails, c'est la fonctionnalité qui est intéressante. L'application va pouvoir demander une fonctionnalité au système en passant par des protocoles spécifiques (via dbus). Tout cela est intégré dans les principaux toolkits (Gtk, KDE) pour que ce soit transparent pour le dev. Il existe des portails pour ouvrir un fichier, afficher une notification, demander à imprimer, et ainsi de suite.
Un exemple concret: un éditeur de texte dans une sandbox ne va pas définir de permissions particulières. Il va utiliser les fonctions traditionnelles de son environnement (par exemple GtkFileChooserNative avec Gtk).
Gtk va détecter la sandbox et demander au système d'ouvrir le fichier pour lui. Le système (via flatpak ou les DE, je sais pas trop) va ouvrir une boite de sélection de fichier, qui sera hors sandbox.
Ce qui est intéressant avec les portails, c'est que ça permet de découpler tout un tas de choses, même en dehors de flatpak. Récemment, Firefox a intégré un patch pour utiliser les portails pour enregistrer les fichiers. Du coup, sous KDE, on peut enfin avoir les boites de dialogues natives.
[^] # Re: Si tous les gens autour de toi sont des cons ...
Posté par BAKfr . En réponse au journal Mais pourquoi flatpak ?. Évalué à 9.
Il y a deux façons d'utiliser les fonctionnalités "bloquées" par la sandbox: soit en configurant les permissions, soit en passant par les portails.
Les permissions de la sandbox sont configurables à deux endroits: coté dev, dans le fichier manifest (le fichier de build de Flatpak); coté utilisateur, c'est actuellement disponible uniquement en ligne de commande.
Je ne sais pas où en est le projet, mais il me semble que la présentation et configuration de ces permissions pour l'utilisateur lambda était un des points prioritaire sur la roadmap du projet.
Par exemple pour le système de fichier, on peut demander à utiliser tout le filesystem, le répertoire $HOME, ou bien un dossier avec un path précis. Le comportement par défaut étant d'avoir seulement quelques dossiers en écriture en utilisant la norme xdg-user-dirs.
Les portails, c'est la fonctionnalité qui est intéressante. L'application va pouvoir demander une fonctionnalité au système en passant par des protocoles spécifiques (via dbus). Tout cela est intégré dans les principaux toolkits (Gtk, KDE) pour que ce soit transparent pour le dev. Il existe des portails pour ouvrir un fichier, afficher une notification, demander à imprimer, et ainsi de suite.
Un exemple concret: un éditeur de texte dans une sandbox ne va pas définir de permissions particulières. Il va utiliser les fonctions traditionnelles de son environnement (par exemple
GtkFileChooserNativeavec Gtk).Gtk va détecter la sandbox et demander au système d'ouvrir le fichier pour lui. Le système (via flatpak ou les DE, je sais pas trop) va ouvrir une boite de sélection de fichier, qui sera hors sandbox.
Ce qui est intéressant avec les portails, c'est que ça permet de découpler tout un tas de choses, même en dehors de flatpak. Récemment, Firefox a intégré un patch pour utiliser les portails pour enregistrer les fichiers. Du coup, sous KDE, on peut enfin avoir les boites de dialogues natives.