(6 Août 2019) Version 1.5.0
Nouveautés par rapport à la 1.4.1
- Fonctionnalités : gestion des partages reçus, que ce soit la racine ou un sous-répertoire, y compris les modes "lecture seule" et "liens cachés" (voir avertissement).
- Documentation : explication de la limitation globale liée à la politique de 1fichier, en plus de l'indication que le driver gère les partages.
Avertissement !
Attention aux partages avec "liens cachés" !.. Ce genre de partage
pourrait être à l'origine d'attaque de la part de celui qui vous a partagé les fichiers.
En effet, comme on n'a plus les liens (ils sont cachés !) la clé d'accès au fichier devient le nom du fichier. Or celui qui vous a partagé le répertoire peut très bien changer les noms de fichier "au bon moment". Ce qu'il pourrait alors arriver est la chose suivante : vous avez commencé à visionner le film de Tonton Jacques en vacance dans un partage reçu, le driver a récupéré un lien de téléchargement et vous a "streamé" le film. Au bout de 30 minutes vous mettez en pause parce que vous recevez un coup de fil. Une fois le coup de fil terminé, vous reprenez le visionnage. A ce moment là, le lien de téléchargement initial est échu et le driver en demandera un nouveau à partir du nom du fichier. Oui mais voila, celui qui vous a partagé le film de vacances de Tonton Jacques, vient de remplacer ce film là par autre chose qui choquerait la vue de vos enfants. Le driver va alors récupérer le lien sur cet "autre chose" et continuer le visionnage à l'adresse où il en était. Il est possible que votre visionneur (VLC, Kodi) shkreugnognote un peu parce qu'il va manquer des trames vidéos, mais la lecture pourrait fort bien se poursuivre sur tout autre chose que le film attendu.
Bien sûr la même "arnaque" peut se produire pour un exécutable (plus difficilement parce qu'on ne le "streame" pas !) avec l'effet d'exécution de code arbitraire.
La défense contre cela :
- essayez d'expliquer à vos amis qui vous partagent des fichiers de
ne PAS utiliser cette fonctionnalité "liens cachés".
- si malgré tout vos amis ne comprennent pas (ou font semblant pour vous arnaquer !), la protection actuelle consiste à utiliser les statistiques et plutôt récupérer les fichiers en local en une seule fois. Vous pouvez alors vérifier avec les statistiques que pour chaque fichier dans le partage, la valeur de
"N. Loc" (représentant le nombre de tickets obtenus) et bien de
1 par fichier, et pas 2 ou plus !.. Ainsi vous êtes assurés de ne pas avoir eu de changement de fichier en cours de téléchargement.
- la protection contre la substitution de fichier en cours de téléchargement serait possible en relisant le "hash" (whirlpool) du fichier, mais cela ralentirait considérablement pour ces fichiers là, et c'est hors de proportion pour une fonctionnalité qui est un peu "bidon".
Une telle chose ne peut pas se produire avec un partage "normal" (lecture seule ou accès complet) car la clé d'accès reste le lien sur lequel l'utilisateur n'a pas la main. Changer le nom d'un fichier ne change pas son lien !.. La seule chose qui pourrait alors arriver est une suppression du fichier partagé en cours de streaming. Mais il n'y a pas de risque de "corruption" volontaire ou pas, juste un risque que l'opération demandée échoue !
Faut-il faire la mise à jour : si vous ne recevez pas de partage de la part de vos amis, la mise à jour n'est pas nécessaire. La version précédente sait tout à fait gérer les partages que vous faites vous-mêmes vers vos amis. Par contre si vous comptez recevoir des partages, la mise à jour est plus que recommandée sinon il y aura des limitations importantes (voir post plus haut) au type de partage que vous pouvez recevoir.
Détails d'implémentation :
- le partage reçu va apparaître sous le nom "nom_du_répertoire" + " on " + "e-mail_de_celui_qui_partage". C'est à dire la même chose que l'on voit sur l'interface 1fichier si on met celui-ci en anglais.
- lorsque c'est la racine qui est partagée, le nom du répertoire transmis par 1fichier est "Root". On a donc "Root on e-mail"
- il existe une différence par rapport à l'interface web si un utilisateur vous fait plusieurs partages imbriqués. Dans ce cas on voit à la racine l'ensemble des partages, comme sur l'interface web, mais quand on déplie l'arborescence, chaque partage garde les droits du répertoire du partage à la racine de votre compte, et on ne voit pas que les sous répertoires sont aussi partagés avec d'autres droits. Ce genre de partage est de toute façon un peu "piégeux" et sans doute un cas d'école !
- meilleur fonctionnement que le site web... sur un "bug" que j'ai signalé à 1fichier, corrigé pour l'API, pas pour le site web. Il s'agit de la suppression de répertoires dans les partages avec accès complet. Vous pourrez le faire avec le driver... pas avec l'interface web. C'est un peu idiot d'avoir accès "total" et de pouvoir créer des répertoires qu'on ne peut ensuite pas supprimer... mais bon ça fonctionne bien via l'API maintenant que le team 1fichier a corrigé.
- le driver filtre les opérations impossibles selon les droits du partage. "Accès complet" permet de tout faire. "Lecture seule" interdit les suppressions, renommages, et copies (lien dur) vers le partage. "Lien cachés" interdit en plus les copies (liens dur) en provenance du partage. Le code retour est "accès refusé". La journalisation détaillée indique que l'opération était impossible. Le statut "lecture seule" est visible sur les droits du répertoire qui sont mis en lecture seule. Ainsi si vous utilisez "default_permissions", c'est le kernel qui filtrera, vous aurez toujours bien accès refusé, mais rien dans le journal puisque le driver ne sera pas appelé, le kernel ayant filtré avant !
- si vous avez activé le plus haut niveau de journalisation (7), le listage fera apparaître un indicateur W, R ou H pour les répertoires partagés selon leurs droits. W (write) pour accès complet, R (read-only) pour lecture seule, et H (hidden) pour liens cachés.
- non testé : les partages "transitifs". C'est à dire Alice partage à Bob, et Bob partage sa racine (qui contient le partage reçu par Alice) à Tom... Cela m'aurait obligé à ouvrir plusieurs comptes de test !.. J'espère simplement que ce cas de transitivité est réglé en ne transmettant pas les partages reçus sur la racine... En effet, Alice a partagé avec Bob, pas avec Tom... donc que Bob s'arroge le droit de partager ce qu'il a reçu d'Alice à Tom peut aller au delà du "consentement" d'Alice sur ce qu'elle souhaitait partager à qui... RGPD etc !..
-
important (et intéressant !) : celui qui vous partage un répertoire n'a pas besoin d'être "premium" pour que vous puissiez utiliser ses fichiers. Un utilisateur "gratuit" vous permettra d'utiliser ses fichiers comme s'ils étaient sur votre compte... tant que celui qui reçoit le partage est abonné "premium". Donc votre fameux "Tonton Jacques" qui souhaite vous partager ses films de vacances, peut très bien prendre un compte
gratuit, y déposer ses films, et vous partager le répertoire où il les a mis (ou la racine). Vous pourrez alors regarder les péripéties du Tonton en vacances avec votre compte premium via
1fichierfs, même si le film a été à la base déposé sur un compte gratuit. 😃
