Le bac à sable c'est sur le principe super pour gérer la sécurité, mais il y a tellement de cas où justement la communication avec l'OS est pas que ouvrir un fichier sélectionné.
Le lien donne un exemple de problème (proposer une intégration dans le navigateur de fichier, pas supporté par le bac à sable qui refuse qu'on touche à cette partie de l'OS), j'en donne un autre : dans mon projet principal j'analyse des fichiers, sélectionnés par l'utilisateur, le bac à sable de navigateur comme Firefox ou Chrome tout comme des OS genre macOS (pas essayé avec Flatpack mais je soupçonne un truc similaire, je testerai quand j'en aurai la motivation), on a le droit de lire le contenu du fichier sélectionné par l'utilisateur, mais que celui-la, adieu les "liens" qui disent dans le fichier sélectionné qu'il faut en fait prendre les fichiers listés pour avoir le vrai contenu. Et ça marche aussi pour genre VLC qui ouvre un fichier principal mais aimerait aussi regarder si il n'y a pas un fichier de sous-titre associé.
Au final, certes la sécurité est importante et le bac à sable part d'un principe que tout est interdit par défaut et on autorise au fur et à mesure, mais il y a un paquet de cas qui restent sur le carreau…
Mais dans ce cas la solution est dans le système de permissions.
Tu indiques à l'utilisateur qu'il faut accorder l'accès au système de fichier (comme c'est fait pour les applications mobiles) et voilà, tu as accès aux fichiers comme avant mais par contre tu n'as pas accès au réseau par exemple. Les portails peuvent donner éventuellement des permissions temporaires par action, du genre, je veux lire tel fichier qui est en dehors du bac à sable mais je le sélectionne et rien d'autre ne sera ouvert.
Cela me semble être un bon compromis. Difficile de faire mieux sans nuire en effet à l'utilisabilité.
# Du classique du bac à sable, un autre exemple
Posté par Zenitram (site web personnel) . Évalué à 3.
Le bac à sable c'est sur le principe super pour gérer la sécurité, mais il y a tellement de cas où justement la communication avec l'OS est pas que ouvrir un fichier sélectionné.
Le lien donne un exemple de problème (proposer une intégration dans le navigateur de fichier, pas supporté par le bac à sable qui refuse qu'on touche à cette partie de l'OS), j'en donne un autre : dans mon projet principal j'analyse des fichiers, sélectionnés par l'utilisateur, le bac à sable de navigateur comme Firefox ou Chrome tout comme des OS genre macOS (pas essayé avec Flatpack mais je soupçonne un truc similaire, je testerai quand j'en aurai la motivation), on a le droit de lire le contenu du fichier sélectionné par l'utilisateur, mais que celui-la, adieu les "liens" qui disent dans le fichier sélectionné qu'il faut en fait prendre les fichiers listés pour avoir le vrai contenu. Et ça marche aussi pour genre VLC qui ouvre un fichier principal mais aimerait aussi regarder si il n'y a pas un fichier de sous-titre associé.
Au final, certes la sécurité est importante et le bac à sable part d'un principe que tout est interdit par défaut et on autorise au fur et à mesure, mais il y a un paquet de cas qui restent sur le carreau…
[^] # Re: Du classique du bac à sable, un autre exemple
Posté par antistress (site web personnel) . Évalué à 4.
C'est le même cas que pour Evince (lire https://blogs.gnome.org/wjjt/2022/05/30/evince-flatpak-and-gtk-print-previews/#comment-17666)
Des propositions sont à l'étude
[^] # Re: Du classique du bac à sable, un autre exemple
Posté par Renault (site web personnel) . Évalué à 5.
Mais dans ce cas la solution est dans le système de permissions.
Tu indiques à l'utilisateur qu'il faut accorder l'accès au système de fichier (comme c'est fait pour les applications mobiles) et voilà, tu as accès aux fichiers comme avant mais par contre tu n'as pas accès au réseau par exemple. Les portails peuvent donner éventuellement des permissions temporaires par action, du genre, je veux lire tel fichier qui est en dehors du bac à sable mais je le sélectionne et rien d'autre ne sera ouvert.
Cela me semble être un bon compromis. Difficile de faire mieux sans nuire en effet à l'utilisabilité.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.