Journal De la bonne façon d'échanger ses fichiers dans un serveur...

Posté par  . Licence CC By‑SA.
Étiquettes :
23
14
nov.
2011

Bonjour à tous et à toutes !

Comme promis, un petit journal sur les problématiques auxquelles nous sommes confrontés dans la mise en place de SOSHIAL.

Bien souvent, dans un contexte de serveur partagé, il est pratique de s'échanger des fichiers entre deux utilisateurs d'un même serveur.
Partons d'emblée du postulat qu'il n'est pas normal que les utilisateurs trouvent plus pratique de passer par un service externe (clef USB, mail, messagerie instantanée, autre...) plutôt qu'utiliser une solution existante sur le serveur et interne au serveur. Quelles sont-elles ces solutions ? Voyons un peu...

Les années précédentes, les droits étaient gérés par ACL (Listes d'accès de fichier).
Les ACL sont des propriétés spécifiques à un fichier qui permettent de se libérer du coté exclusif de la gestion de droit classique.
Les ACL permettent de définir finement les droits sur votre système de fichier. Typiquement il s'agit d'interdire la consultation à tout le monde et de spécifier un à un les utilisateurs et groupes autorisés. C'est donc particulièrement intéressant lors d'un faible partage. Un travail sur un site avec une petite équipe par exemple.

Cependant, le manque d'intuitivité des ACL (nos étudiants sont souvent en première année et découvrent les serveurs linux) et les pansements à rajouter pour permettre la compatibilité avec les nombreuses solutions clef en main (ex: répertoire d'upload Wordpress) nous ont poussé à l'abandonner.

Permettez moi un rapide rappel de cette gestion, même si je ne doute pas qu'il est inutile pour la plupart d'entre vous.
Les droits UNIX sont gérés avec 3 bits : vous, le groupe d'appartenance du fichier et le reste du monde. Afin de respecter l'intimité de chacun, les droits par défaut de toutes les homes sont à 700. Ainsi, personne ne sait ce que vous mettez dans vos dossiers, ça ne les regarde pas.

La plupart du temps, cette solution convient parfaitement. Pour le travail en équipe, il y a les scripts fournis qui créent et configurent un serveur SVN/GIT (ou rajoutent le dépôt à un serveur existant), pour les sites, il y a le panel et les utilisateurs FTP.
Cependant, cette solution ne couvre pas tous les besoins : que se passe-t-il si deux utilisateurs (Alice et Bob) connectés en SSH souhaitent partager la super config de leur éditeur favori ?

  • Solution n°1 : mettre un chmod 755 sur le fichier (et le dossier contenant moult plugins indispensables) pour que notre ami puisse le lire.
    Sauf que non, Alice veut bien montrer sa conf génialissime à Bob, mais pas à tout le serveur non plus. Faut pas déconner.
    Alice et Bob sont tous les deux dans le groupe membres, comme tous les autres utilisateurs du serveur. Un 750 ne changera pas grand chose.

  • Solution n°2 : créer un groupe commun à Alice et Bob et placer l'appartenance à ce groupe (chown alice:my_group .$EDITOR.masuperconf).
    Oui mais non : seul root peut créer des groupes. Et puis il faudra enchaîner un nombre trop important de manipulations pour un simple transfert de fichier (créer le groupe, ajouter les deux utilisateurs, changer l'appartenance du fichier, puis enfin et seulement effectuer la copie).
    A la rigueur on peut imaginer une exception rajoutée dans le fichier sudoers (autoriser un sudo addgroup et delgroup sans mot de passe root) et un script qui grouperait les actions en une seule. Pourquoi pas... ça ne me semble pas idéal mais ça reste une solution potentielle. Ah, non, pas delgroup, il ne faudrait pas supprimer le groupe staff ou membres, ça serait dommage. Bon...

  • Solution n°3 : scp ~/.$EDITOR.mysuperconf bob@localhost:~/
    Ne riez pas, c'est la solution la plus simple lorsque nous parlons d'un nombre réduit d'étudiants dans une salle machine. Alice tape l'instruction de copie et Bob confirme en tapant son mot de passe sur le clavier d'Alice.
    Ce n'est bien sûr pas une solution dans le cadre de SOSHIAL.

  • Solution n°4 : utiliser chown (ou dérivé)
    On copie ça dans un répertoire intermédiaire, comme /tmp, avec des droits à 700, puis Alice chown en faveur de Bob. Ça semble parfait. Sauf qu'il faut être root pour faire un chown. Autoriser le sudo chown ? Mauvaise idée: le chown ne fait pas la différence entre ce qui vous appartenait et ce qui vous appartenait pas. On va éviter le "sudo chown -R user / && chmod -R 700 /", hein. :-)
    Et faire un programme en C qui vérifie les bonnes appartenances ? (appartient à l'utilisateur, l'utilisateur cible est bien un membre et a les quotas nécessaires sur le disque). Avec les suid, c'est possible, la vie semble belle et simple. Sauf que...
    Sauf que ça pose des problèmes de quota disque. Comme il ne vous est pas possible de refuser la propriété d'un fichier, un utilisateur malicieux peut vous remplir votre quota avec un fichier spécialement créé pour. (cf proposition suivante)

  • Solution n°5 : un programme spécifique, adapté à ce besoin précis.
    Déjà avec le programme en C qui appelait le chown dans des conditions précises, on commençait à s'en approcher. Imaginons que nous souhaitions rajouter la possibilité d'accepter ou refuser le partage. Et puis tant qu'à faire le nouveau propriétaire pourrait choisir où il souhaite mettre ces fichiers, ça ne serait pas du luxe.
    On se retrouve donc avec deux programmes différents: un pour proposer le partage, qui se charge de stocker temporairement dans un lieu intermédiaire le(s) fichier(s) et de notifier l'autre utilisateur du partage. Un autre pour vérifier la validité du transfert, récupérer l'ownership via un suid (c'est du C, c'est permis), puis permettre à l'utilisateur d'enregistrer les fichiers ainsi récupérés.
    Oh mais... mais... Mais c'est un mail avec une pièce jointe ! /o\

Non je vous rassure, il ne s'agit pas d'un raisonnement par l'absurde destiné à démontrer la vacuité de cette recherche. :-)
Il s'agit d'un vrai besoin et le mail en ligne de commande n'est pas assez commode pour être un concurrent pertinent.

Finalement l'utilisation de logiciels spécifiques semble la seule solution réellement adaptée (laisser les utilisateurs créer des groupes en pagaille est un peu cavalier), mais je ne vois pas actuellement de tels programmes (et les moteurs de recherches non plus apparemment)

Qu'à cela ne tienne, nous pouvons (et allons surement) coder un tel programme. Mais peut-être, avant de se lancer, connaîtriez-vous un projet libre isolé répondant déjà à ce besoin que nous pourrions récupérer et, pourquoi pas, améliorer ? Tout le jeu est bien sur de se passer des ACL, qui étaient peut-être pas si mal que ça...

  • # ACL

    Posté par  (site web personnel) . Évalué à 9.

    À la lecture de tout ça, j'ai vraiment l'impression que la solution technique, c'est bel et bien les ACL, et que chercher à les éviter ne fera qu'aggraver le problème.

    Si j'ai bien compris, ce qui vous retient d'utiliser les ACL, c'est que

    setfacl -m user:bob:r-- FILE
echo "J'ai un super fichier à te montrer, jette donc un œil sur ~alice/FILE.\n\n-- \nAlice" \
    | mail -s "Un super fichier" bob

    est trop compliqué à taper. Eh bien, codez donc un script partage qui simplifie tout ça pour qu'il suffise de taper :

    partage FICHIER bob

    Au passage, faites en sorte qu'il lance tout seul un éditeur histoire de personnaliser le message, et le tour est joué.

    • [^] # Re: ACL

      Posté par  . Évalué à 5.

      Les problèmes que nous avons rencontré par rapport aux ACL concernaient les logiciels que les utilisateurs s'installaient eux même, et qui prennent rarement en compte la possibilité d'ACL.

      Cela nous a obligé à dépenser une énergie très importante en support qui nous a passé le goût des ACL. Support d'autant plus important qu'il était spécifique à chaque logiciel.

      Pour le reste, c'est génial, et particulièrement dans un environnement multi-user.

      • [^] # Re: ACL

        Posté par  (site web personnel) . Évalué à 1.

        Déjà entendu parler d'ACL par défaut ?

        • [^] # Re: ACL

          Posté par  . Évalué à 0.

          Moi j'en ai entendu parler. Et ça marche pas avec tous les programmes (Samba par exemple au hasard).
          Ou alors j'ai pas bien compris le truc c'est encore très possible.

          • [^] # Re: ACL

            Posté par  (site web personnel) . Évalué à 3.

            Tu n'as pas du bien comprendre. Les ACL par défaut, ce sont des ACL qui sont placées sur une répertoire, et qui sont indiques les ACL à appliquer à tous les nouveaux fichiers créés dedans.

            • [^] # Re: ACL

              Posté par  . Évalué à 2.

              Si si, ça j'avais bien compris, mais soit je n'ai pas compris la manip', soit Samba s'assoit sur les ACL.

              # setfacl -m d:g:users:rwX  /home/partage

              Eh bien chez moi, si /home/partage est (aussi) partagé par Samba, les fichiers écrits via Samba ne seront pas rw pour le groupe (bien que getfacl m'annonce avoir prévu le contraire) et malgré mes recherches sur "samba ACL" j'ai toujours pô réussi.

              Ma source pour la mise en place: commun_utilisateur

              • [^] # Re: ACL

                Posté par  (site web personnel) . Évalué à 3.

                Ah, d'accord. Eh bien justement, c'est parce que Samba gère les ACL. Un logiciel qui ne se préoccupe pas des ACL laisse le noyau s'en charger et appliquer les ACL par défaut.

                Samba, lui, gère donc lui-même les ACL, pour d'excellentes raisons d'ailleurs, mais visiblement ils n'ont pas prévu le coup des ACL par défaut…

                • [^] # Re: ACL

                  Posté par  . Évalué à 0.

                  Faut dire aussi, quelle idée d'utiliser un logiciel implémentant des protocoles orienté purement Windows.

                  Le monde UNIX a tout ce qu'il faut chez lui, pas besoin de solution qui viennent d'autres mondes.

                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                  • [^] # Re: ACL

                    Posté par  . Évalué à 2.

                    Interopérabilité ?

                    • [^] # Re: ACL

                      Posté par  (site web personnel) . Évalué à 5.

                      Comme je l'ai lu une fois dans un autre contexte :

                      On ne peut pas se permettre de laisser Microsoft se mettre en travers du chemin de l'innovation.

                      (sinon, on n'ira nulle part)

                    • [^] # Re: ACL

                      Posté par  . Évalué à 3.

                      Tu m'expliques l'intérêt de Samba entre des Unix ?

                      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                      • [^] # Re: ACL

                        Posté par  (site web personnel) . Évalué à 3.

                        Tu connais une alternative pour faire du montage à distance sécurisé par couple utilisateur/mot de passe ?

                        NFS avec Kerberos peut-être ? Pas de bol, dans « NFS avec Kerberos » il y a Kerberos, une usine à gaz qui demande des heures pour être comprise, et un courage surhumain pour se lancer dans sa mise en place.

                        • [^] # Re: ACL

                          Posté par  (site web personnel) . Évalué à 3.

                          Tu connais une alternative pour faire du montage à distance sécurisé par couple utilisateur/mot de passe ?

                          SSHFS évidemment, mais question performance ça n'a rien à voir, je pense.

                        • [^] # Re: ACL

                          Posté par  . Évalué à 2.

                          Comme dit Tanguy, SSH. Y'a pas plus sécurisé et simple à mettre en place.

                          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                          • [^] # Re: ACL

                            Posté par  (site web personnel) . Évalué à 4.

                            Après le geekscotte « je me réponds à moi-même en trouvant que j'ai vachement raison », il va en falloir un nouveau : « je réponds à quelqu'un qui s'est déjà répondu en trouvant tous les deux qu'il avait quand même vachement raison ».

                        • [^] # Re: ACL

                          Posté par  (site web personnel) . Évalué à 3.

                          C'est pas la mort en 10 jours ça se fait.

                          Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

                      • [^] # Re: ACL

                        Posté par  . Évalué à 1.

                        Entre des Unices, absolument aucun.

                        Le but de Samba est de permettre à des Unices d'interagir avec des OS Microsoft. Ces OS sont certainement puants parce que pas libres, mais refuser de coopérer un tant soit peu avec un OS qu'on retrouve sur plus de 95% des desktops c'est se tirer une balle dans le pied, à mon avis.

                        Et grâce à Samba, lorsque l'on se retrouve dans un parc de stations Windows on peut remplacer un serveur Windows par un GNU/Linux pour un serveur de fichiers.

                        • [^] # Re: ACL

                          Posté par  (site web personnel) . Évalué à 6.

                          Entre des Unices, absolument aucun.

                          Ah, si. Si si. C'est facile à installer (apt-get install samba; smbpasswd untel), facile à configurer (définir deux ou trois partages) et ça marche bien (permissions Unix, ACL, fichiers spéciaux, tout est exporté lorsque le montage est fait sur un Linux).

                          Pour obtenir l'équivalent avec NFSv4 (forcément v4, parce que la v3 n'a qu'une identification par adresse IP, la bonne blague), il faut d'abord mettre en place Kerberos, autrement dit ce n'est en pratique pas faisable.

                        • [^] # Re: ACL

                          Posté par  . Évalué à 2.

                          Sauf que dans l'énoncé, il n'est pas mention de Windows. Il n'est même pas mention de réseau, puisqu'il veut partager des fichiers entre utilisateurs sur le même serveur.

                          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                          • [^] # Re: ACL

                            Posté par  (site web personnel) . Évalué à 3.

                            Il n'est même pas mention de réseau, puisqu'il veut partager des fichiers entre utilisateurs sur le même serveur.

                            C'est pour ça qu'une solution basée sur les permissions UNIX habituelles (ugo) me semble préférable à une solution basée sur un service réseau.

                    • [^] # Re: ACL

                      Posté par  . Évalué à 4.

                      nfs date de bien avant le partage de fichier windows. C'est windows qui devrait se mettre au NFS pas l'inverse :P

                      Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                      • [^] # Re: ACL

                        Posté par  . Évalué à 3.

                        c'est le cas avec les UnixTools (dispo sur le CD d'install de Windows)

  • # Début de piste

    Posté par  (site web personnel) . Évalué à 5.

    Bonsoir,

    les ACL, pas sexy et peu gérable oui, mais cela s encapsule assez bien dans des scripts plus utilisable pour/par les néophytes.

    Pour le mail avec pièces jointe on peut utiliser uuenview et uudevview ce qui permet d encapsuler les pièces jointes et de les rendre utilisables.

    et oui le mail ce n'est pas génial.

    sinon pour ton petit programme en C, il y a déjà sudo qui pourrais faire l'affaire, en lançant un script par exemple qui demanderais plusieurs paramètres comme le user destination, le fichier (ou répertoire) à copier. Celui ci enverrais vers un /tmp avec les vérification de sécurité qui s'impose (faire un check des tailles, précédence de l'existence du répertoire...) les données qui appartiendrais au user cible.

    une autre solution, plus élégante serais de faire cela avec ssh en créant une entrée dans le $HOME/.ssh/authorized_keys qui n'autoriserais que la prise des données souhaitées, comme cela.

    command="/usr/local/bin/get_file.sh",no-X11-forwarding,noagent-forwarding ssh-rsa AAAA..

    et le script en question ferait quelque chose comme d envoyer en flux une tar ball. (tar cvfj -

    ta récupération serais donc facile avec un |tar xvfj -

    Voila pour un début de piste. mais ça ne me semble pas impossible ni très compliqué a mettre en place et à expliquer
    peut être mettre un audi des $HOME/.authorized_keys pour prévenir les utilisateurs de la présence de l entrée

    • [^] # Re: Début de piste

      Posté par  . Évalué à 2.

      Wow, la solution élégante à base de SSH répond exactement à notre problématique, mais je ne comprends pas comment tu la mets en place.
      Le fichier authorized_keys se contente de lister les clefs qui peuvent se connecter sans avoir à taper de mot de passe, non ? La manpage de ssh(1) ne semble pas me contredire...

      Tu pourrais expliquer plus en détail ce à quoi tu pense ?

      • [^] # Re: Début de piste

        Posté par  (site web personnel) . Évalué à 3.

        C'est une possibilité que j'ai découvert récemment en cherchant à comprendre comment marche gitosis, qui a exactement la même problématique: permettre à l'utilisateur de n’exécuter que certaines commandes.
        Comme le dit SauronDeMordor, avant le blabla de la ligne, tu peux rajouter des parametres qui forcent certains réglages SSH en fonction de la clé en question, en particulier on peut forcer le serveur SSH a exécuter une certaine commande.
        Dans le manpage sshd de ma distrib (je sais pas si c'est spécifique), il y a une section "AUTHORIZED_KEYS FILE FORMAT" qui décrit en détail les possibilités.

      • [^] # Re: Début de piste

        Posté par  . Évalué à 4.

        Wow, la solution élégante à base de SSH répond exactement à notre problématique, mais je ne comprends pas comment tu la mets en place.

        Bob met la clé d'Alice dans son authorized_keys, avec la commande qui va bien, et Alice fait le ssh vers bob@localhost | tar xf pour récupérer le fichier. Un truc simple quoi.

        Je ne vois pas en quoi c'est élégant, c'est au contraire plutôt lourd à mettre en place pour du partage de fichier à la demande. Ton script 'getfile.sh' a intérêt d'être bien écrit, testé et sécurisé pour éviter toutes sortes de problèmes de prise de main, suppression de données, dépôt de trucs divers et variés. Et pour finir, bonjour la gestion des clés.

        Comme je te l'avais dit sur la tribune, une solution 5 mais basée sur des ACL au lieu du chown, avec diverses options (création de liens, mail de notice, fichier attaché, etc) serait, je pense, plus pertinent.

      • [^] # Re: Début de piste

        Posté par  (site web personnel) . Évalué à 3.

        Comme dit dans une autre réponse, on trouve cela dans le man, même si on ne lit pas souvent cette partie dans le man de sshd
        c'est dans la section AUTHORIZED_KEYS FILE FORMAT

        on vois donc comment est fait ce fichier et ses fonctionnalités.

        command="command" Specifies that the command is executed whenever this key is used for authentication...

        Cela dit je suis quand même d'avis que la meilleur façon serait les ACL. mais on peut aussi penser à une publication web. Un script php qui génère un zip suivant certains paramètres, ou même, que les user envois sur le site les fichiers à partager (sorte de dl.free.

        une autre solution est que si c'est pour partager des fichiers de config/paramètres users le mieux serais de créer un endroit ou plein de config (plus sympa que celle par défaut) soit stockées.

  • # A la fois bien et pas bien.

    Posté par  (site web personnel) . Évalué à 2.

    Chmod 755 avec cryptographie à clef publique.

  • # [HS][mais pas trop] Meme pb pour échanger des fichiers sur Internet

    Posté par  (Mastodon) . Évalué à 4.

    Plop,

    J'ai un soucis très similaire : je loue un serveur dédié (donc riche en disque dur et en bande passante) et je sous-loue à différents utilisateurs. L'un d'eux, a le besoin (entre autre) de pouvoir échanger des fichiers de grande taille (100aines de Mo) assez facilement (affiche en haute résolution, master de CD etc.)

    Bin je galère à leur faire utiliser un simple FTP, et ils continuent d'utiliser des service style Dropbox (ou je ne sais quel autre service dans le style).

    Du coup je suis en train d'écrire une appli dédiée, aussi simple que DropBox qui leur permettra d'avoir la même souplesse, sans aucune limitation.

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # Windows !

    Posté par  . Évalué à 3.

    C'est dingue, sous Windows ça se fait en quelques clics depuis des années pour partager un document ou un dossier sur un serveur ou sur un réseau local.
    Je n'imaginais pas qu'un cas d'utilisation aussi simple n'ait toujours pas d'outillage adapté en environnement UNIX.

    Peut-être que la meilleur voie est l'utilisation de SAMBA (c'est ce que fait MacOSX, en complément du protocole maison AFP).

    BeOS le faisait il y a 20 ans !

    • [^] # Re: Windows !

      Posté par  . Évalué à 5.

      peut être parce que c'est de la gestion en remote sans interface graphique (perso je ne vois que ça) ;)

      Sous konqueror 3.5.4 (celui que j'ai au boulot) un clique droit sur un fichier me donnes accès aux droits communs du fichier, et un clique sur propriété avancée me donne accès aux acl avec une gestion facile de ceux ci (utilisateur, groupe, masques...)

      Vas y pour gérer les droits de ficher sous windows sans avoir accès à une fenêtre explorer ;)

      Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: Windows !

      Posté par  (site web personnel) . Évalué à 2.

      Mwai, enfin si j'ai bien compris la problèmatique des ACLs, c'est que ce sont des serveurs sans X donc pas moyen d'utiliser des outils simples pour gérer les ACLs... (dolphin, nautilus, ...).

      Parce que bon, sous windows avec iacls, c'est pas non plus très adapté à un étudiant en première année (quoi que...)

      • [^] # Re: Windows !

        Posté par  . Évalué à 1.

        oui enfin avec un sftp://boulet@corporation.com:/tmp/plop dans la barre d'url de konqueror permet de changer les acl des fichiers de boulet. Je peux pas tester avec dolphin il est pas installé sur l'ordi du bureau, mais je pense que ça marche aussi.

        Donc c'est sans X et sans sftp (ssh) ;)

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: Windows !

          Posté par  (site web personnel) . Évalué à 4.

          Quand je dis sans X, ca veut dire tout en ligne de commande, comme tout bon étudiant devrait commencer à apprendre Unix...

          • [^] # Re: Windows !

            Posté par  . Évalué à 2.

            c'est une idée qui se défend;

            Perso j'ai appris l'info sous dos, puis sous win 98, et pour la suite c'était unix & linux en IUT;

            Si tu présentes aujourd'hui une interface ligne de commande à quelqu'un qui n'a connu que 7 ou mac OS, tu vas le faire fuir, ou avoir des remarque comme quoi c'est plus 'simple' (comprendre que cela fait appel à la mémoire visuelle) sous windows.

            Alors que si tu commence par lui présenter les deux manières de faire, (graphique et interface texte), et que tu lui demandes de faire des trucs de plus en plus complexe, naturellement la ligne de commande finira par s'imposer car elle est incroyablement plus souple que l'interface graphique.

            et oui utiliser des scripts partager est enfantin et nettement plus rapide que clique droit, propriété, propriété avancer, ajouter règle, utilisateur, ...

            mais montrer aux utilisateurs les deux manières de faire évite de se prendre un j'ai pas envie d'utiliser ton truc démodé (même si à mon avis ce ne serait pas une grande perte)

            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

          • [^] # Re: Windows !

            Posté par  . Évalué à 2.

            Ben oui, avec gvfs ça se fait tout en ligne de commande, cf gvfs-ls, gvfs-cp, gvfs-mv, etc. En plus, il fonctionne avec fuse et permet aux programmes non prévus pour d'y accéder.

            Et je suppose que KDE propose un équivalent.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Windows !

      Posté par  . Évalué à 6.

      T'as pas essayé de partager des fichiers entre Seven et Vista, toi…

      Une heure pour transférer trois fichiers à la con, avant de comprendre que Seven utilise la notion de réseau confidentiel que ne connait pas Vista…

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Windows !

      Posté par  (site web personnel) . Évalué à 1.

      C'est dingue, sous Windows ça se fait en quelques clics depuis des années pour partager un document ou un dossier sur un serveur ou sur un réseau local.

      1) c'est pas faux. Malheureusement, c'est pas parce que tu as cliqué sur partager que le fichier est accessible sur d'autres machines (pb rencontré sur une machine windows 7, ni une autre machine sous windows ni une autre machine sous linux n'accédait aux fichiers)

      2) c'est dingue, sous linux, partager un document ou un dossier, ça se fait en un clic. Oui, j'ai rebooté le serveur du paragraphe précédent sous linux (mint), j'ai cliqué sur partager dans nautilus et les deux autres machines ont eu accès au fichier.

  • # /tmp

    Posté par  (site web personnel, Mastodon) . Évalué à 1.

    Pourquoi pas simplement tout copier dans /tmp en chiffrant avec GnuPG pour chaque destinataire ?
    En plus, on peut même imaginer un script qui le fait en interrogeant un serveur (LDAP, serveur de clés standard) contenant les clés publiques de chacun des utilisateurs de la machine.

    • [^] # Re: /tmp

      Posté par  . Évalué à 2.

      Ca oblige à copier le fichier (et donc à utiliser deux fois sa taille). C'est un peu dommage.

      • [^] # Re: /tmp

        Posté par  (site web personnel) . Évalué à 1.

        c'est surtout un méga-trou de sécurité pour des fichiers privés (liste de mots de passe par exemple...), lisible par tout le monde :/ la gestion des groupes (scénario 2) est plus maîtrisable déjà, cf. plus bas...

        • [^] # Re: /tmp

          Posté par  (site web personnel, Mastodon) . Évalué à 0.

          Je suis d'accord que ça ne résoud pas le problème des droits à proprement parler mais ça règle déjà le problème de la confidentialité du contenu.
          En effet, même si ton fichier de mots de passe est lisible par tous, son contenu chiffré ne l'est pas et je pense que le temps de cassage du chiffrement est bien supérieur à la durée de validité des mots de passe contenus.
          Par contre, encore une fois, il est vrai que cela ne résoud pas le problème de l'utilisateur qui efface un fichier dont il n'est ni le destinataire ni le propriétaire.

    • [^] # Re: /tmp

      Posté par  . Évalué à -2.

      GnuPG, LDAP, un script, des clés privées pour tout le monde, tout simplement

    • [^] # Re: /tmp

      Posté par  . Évalué à -9.

      • il est ou ton fichier?
      • ben dans /tmp
      • t'as craque, il est vide ton repertoire
      • ah ben ca alors! J'aurais pourtant jure l'avoir copie la dedans hier...

      If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

      • [^] # Re: /tmp

        Posté par  . Évalué à 2.

        Forcément, si on met en place une solution de ce genre, on s'assure que le /tmp est pérenne et pas vidé régulièrement.

        Au pire, on peux utiliser autre chose comme /share. Ce qui importe, c'est l'idée, pas l'implémentation.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: /tmp

          Posté par  . Évalué à -8. Dernière modification le 14 novembre 2011 à 20:55.

          J'adore ce concept.

          Bon les gars, on a un problème.
          Les acl c'est un merdier sans nom.
          Alors, plutôt que de résoudre le problème comme il faudrait, à savoir implémenter les ACL comme le font tout le monde depuis 10 ans, on a un paquet de solution à la con en échange :

          • Créer des groupes pour chaque couple d'utilisateur
          • tu veux vraiment avoir 875 groupes sur la machine et les créer toi-même?
          • Bon ok. Donner un shell ssh à la personne en question
          • Heu ouais mais non, je ne donne pas un shell à la personne en question. Désolé.
          • Bon alors, on va prendre un répertoire désigné pour être temporaire. Comme ça va poser des problèmes, on va le rendre temporaire, c'est génial comme idée non ?
          • Super ! Et les applications qui partent du principe que c'est temporaire et vont foutre tout un bordel dedans qui va saturer le disque, t'en fait quoi.
          • Raaah. Non, mais je te dis, je tiens ABSOLUMENT à ne pas résoudre le problème comme il devrait être résolu. C'est une question d'honneur ! Les ACL ne passeront pas par moi !

          Sérieux, c'est si dur que ça d'admettre qu'il faut un vrai système d'ACL qui marche bien et que le system user/group/world est pourri et inadapté au possible ?

          If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

          • [^] # Re: /tmp

            Posté par  (site web personnel) . Évalué à 2.

            Parce que les ACL sont faites pour cela, que ca marche bien, que peut d appli pose problme avec.

            le seul hic et pas des moindres c'est l'utilisateur (encore lui) qui veut faire des chose pas spécialement définie ou adaptée.

            ici le contrat c'est de partager de façon déterministe et sécurisé des données utilisateurs.

            ensuite on peux réfléchir a comment et pourquoi:

            • données persistantes ou temporaires
            • pour faire des copies ou utiliser en place
            • à ton vraiment besoin que les données soient "sécurisées"

            on pourrait donc avoir des réponse très différentes à notre problème.

            le DAC n'est pas pourris, les ACL non plus, comment on les met, c'est un autre problème (windows ou linux, c'est pareil) car peu d'utilisateur ne les comprennent pas et donc en font une utilisation erronées.

            pour nfsv4, pas besoin de kerberos, ça marche très bien sans, mais on peut mettre une couche de sécurité via kerberos dessus, et il y a donc un service à gérer et a mettre en place ( le domaine nfsv4).
            pour kerberos, c'est pas si compliqué a mettre en place tout admin qui gère des environnement mixte (UNIX/Linux - Windows) connait ça très bien (ou devrait s'y intéresser), et cela facilite beaucoup le boulot via la gestion des outils de Activedirectory.Par contre c'est vrai qu'il y a une grosse marche a monter.

          • [^] # Re: /tmp

            Posté par  . Évalué à 3.

            Gné ? Il est où le problème avec les ACL ? J'ai jamais dit que c'était pourri, je trouve bien au contraire que c'est un truc excellent mais pas adapté à tous les usages.

            Et surtout, en quoi sont-elles mieux implémentées par le reste du monde ?

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: /tmp

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Pas faux :D

  • # DCC

    Posté par  (site web personnel, Mastodon) . Évalué à 0.

    Et pourquoi pas utiliser l’extension DCC d'irc ?
    C'est ce qu'on utilise de temps en temps ici entre collègues.

  • # Dossier `drop`

    Posté par  (site web personnel) . Évalué à 8.

    Configuration:

    Le dossier alice a les permissions 711.
    Le dossier alice/drop a les permissions 733.

    Propriétés:
    bob peut écrire des fichiers dans alice/drop
    bob ne peut lister des fichiers ni dans alice ni dans alice/drop
    alice peut effacer les fichiers dans alice/drop même s'ils ne lui appartiennent pas
    victor peut bien se brosser pour afficher le contenu du dossier alice/drop

    Est-ce que ce n'est pas à la fois simple et satisfaisant?

    Puisque bob doit rendre ses fichiers lisibles par alice et donc par tous les autres étudiants (ou tous les membres du groupe member), le méchant victor peut lire le fichier que donne bob à alice s'il connaît le nom de celui-ci. Si ce risque est sérieux, on peut créer des scripts pour la manipulation de la boîte qui ajoutent des préfixes aléatoires aux fichiers lors de leur copie dans '*/drop' et les suppriment lorsqu'ils sortent de '*drop', cela donnera bien du fil à retordre à ce salaud de victor!

    • [^] # Re: Dossier `drop`

      Posté par  . Évalué à 1.

      Avec cette solution, Ève pourra remplir le dossier ~bob/drop que Bob ne pourra plus supprimer !

      • [^] # Re: Dossier `drop`

        Posté par  . Évalué à 1.

        À condition de mettre le "sticky bit" sur le dossier, sinon les autres utilisateurs peuvent écraser les fichiers que Alice aura déposé.

        • [^] # Re: Dossier `drop`

          Posté par  (site web personnel) . Évalué à 3.

          Le sticky bit sur un dossier sert à ce que seul le propriétaire du dossier ait le droit d'effacer les fichiers contenus par le dossier, et ce même si d'autres autilisateurs ont le doirt d'écriture dans le dossier. Ils peuvent cependant créer des fichiers dans le dossier en question et les protéger de l'écrasement en effaçant les bits write des permissions.

      • [^] # Re: Dossier `drop`

        Posté par  (site web personnel) . Évalué à 2.

        bob a le droit d'écriture sur ~bon/drop et en est le propriétaire, donc a le droit d'y supprimer les fichiers qui ne lui appartiennent pas.

        cf. http://linux.die.net/man/2/unlink ou http://www.freebsd.org/cgi/man.cgi?query=unlink&sektion=2

      • [^] # Re: Dossier `drop`

        Posté par  (site web personnel) . Évalué à 3.

        PS: pourquoi ne pas reprendre les notations de l'énoncé (alice, bob, victor) ? Ce serait quand-même plus facile à suivre.

      • [^] # Re: Dossier `drop`

        Posté par  (Mastodon) . Évalué à 7.

        T'es sûr de ça ?
        Si Ève copie des fichiers dans ~bob/drop, ces fichiers appartiennent toujours à Éve normalement.
        Par contre le répertoire appartenant à Bob, il a parfaitement le droit de les effacer, même s'ils ne sont pas à lui.

        root@lrogg:~# touch /home/moi/a
        root@lrogg:~# chmod 700 /home/moi/a
        root@lrogg:~# ls -al /home/moi/a
        -rwx------ 1 root root 0 nov. 14 12:28 /home/moi/a*

        moi@lrogg:~$ ls -al a
        -rwx------ 1 root root 0 nov. 14 12:28 a*
        moi@lrogg:~$ chown moi a
        chown: changement de propriétaire pour « a »: Opération non permise
        moi@lrogg:~$ chmod 777 a
        chmod: modification des permissions de « a »: Opération non permise
        moi@lrogg:~$ cat a
        cat: a: Permission non accordée
        moi@lrogg:~$ rm a
        rm : supprimer fichier vide (protégé en écriture) « a » ? y
        moi@lrogg:~$ ls -al a
        /bin/ls: impossible d'accéder à a: Aucun fichier ou dossier de ce type

        Aucun soucis et même si le fichier appartient à root.
        Donc Éve ne peut pas blinder le quota de Bob, elle blindera le sien, et Bob peut quand même faire le ménage comme il veut dans sa propre maison.

        C'est pas suffisant comme fonctionnement ça ?

        Yth.

        • [^] # Re: Dossier `drop`

          Posté par  . Évalué à 1.

          Vous avez raison, j'ai déjà eu un problème avec ça il y a un moment, et je croyais avoir déduit que le propriétaire du dossier ne pouvait plus supprimer ses fichiers avec le sticky bit, mais il semblerait que c'est faux.

          • [^] # Re: Dossier `drop`

            Posté par  (site web personnel) . Évalué à 2.

            j'ai déjà eu un problème avec ça il y a un moment, et je croyais avoir déduit que le propriétaire du dossier ne pouvait plus supprimer ses fichiers avec le sticky bit

            Sous FreeBSD le sticky bit des fichiers ordinaires est ignoré. Sous Linux, il me semble que ce soit aussi le cas.

            J'ai déjà vu des fichier append only, c'était par exemple le cas du fichier ~/.ssh/authorized_keys sur une machine à mon travail, ce qui permettait à root d'être sûr que certaines clefs importantes pour le système ne soient pas effacées de ce fichier. Mais ce genre d'effet n'a (sauf customisation locale) rien à voir avec le sticky bit.

          • [^] # Re: Dossier `drop`

            Posté par  . Évalué à 4.

            il faut bien comprendre ce pour quoi est faire le sticky bit.

            pour /tmp
            le dossier appartient à root:root
            il est en droit 1777 (donc sticky)

            n'importe quel utilisateur peut ecrire dedans
            mais Bob ne peut pas effacer les fichiers deposer par Alice
            ni Alice effacer les fichiers de Bob
            c'est le but du sticky bit

            par contre root (dieu tout puissant) peut effacer les fichiers de tous les utilisateurs

            • [^] # Re: Dossier `drop`

              Posté par  (site web personnel) . Évalué à 3.

              par contre root (dieu tout puissant) peut effacer les fichiers de tous les utilisateurs

              En l'occurence ce qui compte est que root est le propriétaire du dossier portant le sticky bit.

  • # transfert par netcat

    Posté par  . Évalué à 9.

    pour remplacer la solution 3, bob n'a plus besoin d'aller taper son mot de passe sur un autre clavier (et être sur le même serveur ne signifie pas être dans la même pièce)

    extrait du man de netcat, section DATA TRANSFER :

    Start by using nc to listen on a specific port, with output captured into a file:

      $ nc -l 1234 > filename.out

Using a second machine, connect to the listening nc process, feeding it the file which is to be transferred:

      $ nc host.example.com 1234 < filename.in

After the file has been transferred, the connection will close automatically.

    peut aussi se faire dans l'autre sens en inversant les rôles

    • [^] # Re: transfert par netcat

      Posté par  . Évalué à 3.

      Ça pourrait se scripter afin de proposer à chaque utilisateur un "serveur de réception" qui se charge d'écouter sur un port donné, de recevoir les fichiers, de les stocker, de dire "stop" quand c'est plein..

      Bonne idée :)

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: transfert par netcat

        Posté par  . Évalué à 5.

        Et on pourrait normaliser le protocole, et l’appeler FTP par exemple.

      • [^] # Re: transfert par netcat

        Posté par  . Évalué à 2.

        Donc tu crées un serveur, qui écoute sur un port, avec donc un protocole. Tu vas avoir besoin

        • d'un minimum d'authentification
        • d'une gestion du transfert, en particulier, quelle taille, on s;arrte où ? on va tout de meme pas refermer le tuyau à chaque fichier
        • d'une gestion de repertoire pour savoir où tu le mets.

        Et après il faudra le nomer, je te propose d'appeler ce protocole File_Transfer_Protocol.

        • [^] # Re: transfert par netcat

          Posté par  (site web personnel) . Évalué à 4.

          FTP est une vieillerie non sécurisée, empoisonnante pour les pare-feux avec son utilisation de deux canaux de communication. Et sa version sécurisée est par nature totalement inutilisable derrière un pare-feu.

          Par ailleurs, à part des usages extrêmement spécifiques — l'envoi anonyme et la récupération anonyme récursive — ses fonctionnalités peuvent être mises en œuvre en utilisant deux protocoles mieux fichus : SFTP pour l'envoi identifié et la récupération identifiée récursive, et HTTP pour la récupération anonyme ou identifiée. Ces fonctionnalités peuvent être complétées avec DAV, voire sans DAV mais en pratique ce sont les clients DAV qui implémentent des trucs comme l'envoi de fichiers par HTTP.

          • [^] # Re: transfert par netcat

            Posté par  (site web personnel, Mastodon) . Évalué à 4.

            Sauf que HTTP, c'est pour Hyper Text et va bien falloir arrêter d'en faire un protocole qui transporte autre chose que de l'hypertexte.
            Et puis, FTP est chiant à configurer mais c'est quand même loin d'être infaisable.
            Quant au problème de la vieillitude de la chose, ça n'a, pour moi, aucune espèce d'importance mais c'est parce que je suis aussi vieux que lui... Un peu comme SMTP.

            • [^] # Re: transfert par netcat

              Posté par  . Évalué à 4.

              Tu n'as pas tort du tout:

              grep -v ^# /etc/services | wc -l
550

              C'est dingue cette habitude de décider péremptoirement que, pour les 9/10 des usages d'Internet, parmi ces 550 protocoles, c'est forcément HTTP qui conviendra.

              THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

              • [^] # Re: transfert par netcat

                Posté par  (site web personnel, Mastodon) . Évalué à 1.

                C'est dingue cette habitude de décider péremptoirement que, pour les 9/10 des usages d'Internet, parmi ces 550 protocoles, c'est forcément HTTP qui conviendra.

                C'est pas péremptoire, c'est juste par facilité qu'aujourd'hui tout le monde veut faire tout sur HTTP.
                Ca permet de se gaver de webservices en SOAP qui sont connus pour leur grande performance et leur faible encombrement réseau.
                Et puis, c'est bien parce que comme ça, quand on fait un firewall, on peut uniquement ouvrir un ou deux ports, le 80 et/ou le 8080.

                Comme dit plus bas, 9/10 du Web, ok, mais pas de l'Internet. Perso, je pense que le mail occupe une très grande place dans la consommation de l'Internet et on n'a pas encore décidé de passer les envois de mails sur HTTP.

                • [^] # Re: transfert par netcat

                  Posté par  (Mastodon) . Évalué à 4.

                  « et on n'a pas encore décidé de passer les envois de mails sur HTTP. »
                  Au niveau utilisateur, si, et depuis longtemps...
                  C'est tout le principe du webmail, tout en HTTP.
                  Après que les serveurs parlent en autre chose n'a aucune importance pour l'utilisateur, lui il n'a, encore une fois, que du HTTP !
                  Affichage, pièces jointes, envoi, listes de contact, c'est souvent 100% web...

                  Yth, réfractaire aux webmails à titre personnel.

                  • [^] # Re: transfert par netcat

                    Posté par  (site web personnel, Mastodon) . Évalué à 1.

                    Sauf que là, on rejoint le Web et l'utilisation dans ce cas, c'est plus du transfert de fichier. Le webmail, c'est un site Web comme un autre donc on sort du sujet.
                    On resterait dans le cas dont on discute si on s'amusait à implémenter le SMTP dans un WebService qui utilise HTTP comme "transport".

                    • [^] # Re: transfert par netcat

                      Posté par  (Mastodon) . Évalué à 4.

                      Tout les services web finalement ce sont des sites webs comme les autres...

                      Par exemple, ajaxterm, c'est du login via HTTP.
                      L'interface web d'un serveur aMule c'est du bittorrent vai HTTP.
                      Le webmail c'est du SMTP/IMAP/POP via HTTP.

                      C'est bien ça aussi le tout HTTP, tout en services web.
                      Qu'on ait un client lourd en local qui encapsule un protocole en HTTP, ou un service web à l'extérieur qui sert d'interface, ça revient strictement au même.
                      De toute façon, « à l'extérieur », de serveur internet à serveur internet, ce genre d'encapsulation n'a pas d'intérêt : les ports sont ouverts, et globalement les « bons » protocoles sont utilisés.

                      C'est bien de ça dont tu parles finalement : tout faire passer sur le port 80/8080/443 !
                      Quelle que soit la méthode utilisée (en gros si le HTTP est utilisé pour le protocole avec un client local ou directement pour l'IHM), le résultat est le même : un service qui a son protocole, sa manière de faire, ses spécifications, se retrouve sur du HTTP pour l'utilisateur.

                      Je ne vois juste pas de raison de faire une réelle distinction, à mon sens c'est du chipotage...

                      Yth.

                      • [^] # Re: transfert par netcat

                        Posté par  (site web personnel, Mastodon) . Évalué à 1.

                        Non, y a une réelle différence entre fournir une interface web à un utilisateur et coder un protocole au-dessus d'HTTP en remplacement d'un protocole de même niveau qu'HTTP, au sens OSI du terme.
                        Tu parles de l'interfaçage Web qui ne me gêne pas en soi vu que c'est le but même d'HTTP, fournir via un navigateur du contenu.
                        Par contre, quand tu parles de client lourd qui encapsule un protocole en HTTP, là, je tique car il s'agit bien d'utiliser HTTP pour en faire une couche équivalent à du transport alors qu'il fait partie de la couche Application.
                        HTTP, ce n'est pas un moyen de faire des connexions, c'est une fin en soi et le but est bien le transfert de contenu.

                        Pour conclure, qu'HTTP serve à fournir une présentation Web à un serveur qui cause ensuite sur le Net avec un vrai protocole, pas de problème mais réécrire, en ASCII qui plus est, un protocole dans les trames HTTP, là, c'est trop.

                        Comme je l'ai dit plus bas, je rejoins bien l'avis de ce post.

            • [^] # Re: transfert par netcat

              Posté par  (site web personnel) . Évalué à 3.

              Sauf que HTTP, c'est pour Hyper Text et va bien falloir arrêter d'en faire un protocole qui transporte autre chose que de l'hypertexte.

              Ça tombe bien, HTTP est très mal nommé, parce qu'il n'a strictement rien à voir avec l'hypertexte. C'est un protocole de téléchargement et d'envoi de fichiers.

              Je répète les problèmes de FTP : ça passe mal les pare-feux, ce n'est pas sécurisé du tout et quand on essaie de le sécuriser ça ne passe plus du tout les pare-feux.

              • [^] # Re: transfert par netcat

                Posté par  (site web personnel, Mastodon) . Évalué à 1.

                D'où l'intérêt de tout ce qui est méta rajoutées au fur et à mesure.
                Ceci dit, on peut aussi utiliser une marteau piqueur pour tuer une mouche.
                Ca me rappelle ça.

              • [^] # Re: transfert par netcat

                Posté par  . Évalué à 2.

                Personnellement, j’ai un VsFTPd qui est accessible par n’importe qui !

                Et l’avantage d’un VsFTPd sur n’importe quel serveur Web c’est que, quand je me connecte, le serveur fork et change ses droits (en gros, il tournera en arcaik:users ou arcaik:ftp) et sinon (connexion anonyme), utilise des droits par défaut (ftp:ftp). En fait, c’est le même comportement que SSH en ajoutant les connexions anonymes.

                Aucun serveur Web ne fait ça. Sur un poste multi-utilisateurs, niveau sécurité, c’est pas top !

                • [^] # Re: transfert par netcat

                  Posté par  . Évalué à 2.

                  Désolé, j’ai mal écrit mon commentaire.

                  La première phrase repondait à :

                  ça passe mal les pare-feux

                  Le reste du commentaire répondait en partie à :

                  ce n'est pas sécurisé du tout et quand on essaie de le sécuriser ça ne passe plus du tout les pare-feux

                  Et je rajouterai que niveau sécurité, HTTPs ou FTPs (et pas SFTP) c’est égale.

          • [^] # Re: transfert par netcat

            Posté par  . Évalué à 6.

            Comme le dit Blacknight, HTTP c'est surtout pour du texte et du contenu. Il y a d'autre protocoles, conçus spécifiquement pour le partage de fichiers.

            C'est dingue, tous ces gens qui confondent web et internet :-)

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Chown

    Posté par  . Évalué à 2.

    Je dis peut-être une bêtise, mais faire un :

    chown moi:toi fichier

    Le propriétaire reste le même, par contre on place la personne avec qui on veut partager le fichier comme groupe. Les quotas devraient être respectés, et idéalement on ne fait que placer le fichier en visible/pas modifiable (à « toi » de le copier dans son répertoire).

    • [^] # Re: Chown

      Posté par  (Mastodon) . Évalué à 3.

      Il ne me semble pas que l’existence d'un groupe au nom de l'utilisateur soit toujours le cas sous Linux.
      Par exemple j'utilise une distribution qui n'a jamais fonctionné comme ça.
      Je n'ai jamais vraiment vu l'intérêt, mais en l’occurrence, peut-être qu'il y en a un.
      Par contre si tu n'es pas toi-même dans le groupe « toi », peux-tu donner un fichier à ce groupe là ?
      Moi j'ai « chgrp: modification du groupe de « a »: Opération non permise » quand j'essaie de donner un fichier à un groupe auquel je n'appartient pas.

      Et si on met tout le monde dans les groupes de tout le monde, alors ça ne sert à rien, tu donnes un fichier au groupe de « toi », et tout le monde peut le lire...

      Yth.

      • [^] # Re: Chown

        Posté par  (site web personnel) . Évalué à 2.

        Par contre si tu n'es pas toi-même dans le groupe « toi », peux-tu
        donner un fichier à ce groupe là ?

        Effectivement, je savais pas ca :)

        Mais bon, pour le coup, un petit script qui fait ce qu'il faut avec les acls me semble assez adapté...

        • [^] # Re: Chown + groupe

          Posté par  (site web personnel) . Évalué à 2.

          Sous http://vhffs.org les utilisateurs peuvent travailler sur un projet commun (il suffit de se déclarer dans le même projet). Évidemment, comme l'hébergement est sous GNU/Linux, la notion de projet correspond exactement à la notion de groupe (pas besoin d'aller jusqu'à des ACL...). VHFFS est le logiciel de forge utilisé par TuxFamily pour gérer l'hébergement des projets, visiblement ceux qui en ont besoin pour faire du travail collaboratif y arrivent ;-)

          Il y a un exemple sur https://panel.tuxfamily.org (pour ceux qui ont déjà un compte voire un projet).
          Sinon, il y a la doc' sur http://faq.tuxfamily.org/Group/Fr#Description

          les répertoires htdocs appartiennent au groupe et sont en 775(*), ce qui permet de maintenir le contenu à plusieurs.

          (*) plus précisément, en drwxrwsr-x permettant aux « bons » clients utilisés pour uploader d'hériter des droits kivonbien pour travailler à plusieurs :)

    • [^] # Re: Chown

      Posté par  (site web personnel) . Évalué à 2.

      Tu ne dis pas vraiment de bétise, c'est au moins vrai pour les distribs à base de redhat/debian.

      Mais sur les distribs plus bsd like ou sur les système Unix, les utilisateurs sont dans le groupe users et donc cela ne fonctionnera pas...

  • # C'est peut-être naïf, mais...

    Posté par  (site web personnel) . Évalué à 1.

    Dans la solution 4:
    «Et faire un programme en C qui vérifie les bonnes appartenances ? (appartient à l'utilisateur, l'utilisateur cible est bien un membre et a les quotas nécessaires sur le disque). Avec les suid, c'est possible, la vie semble belle et simple. Sauf que...
    Sauf que ça pose des problèmes de quota disque. Comme il ne vous est pas possible de refuser la propriété d'un fichier, un utilisateur malicieux peut vous remplir votre quota avec un fichier spécialement créé pour. (cf proposition suivante)»

    Quitte à faire un programme suid pour faire du chown, il suffirait pas de faire en sorte que ce programme vérifie que le nouveau propriétaire du fichier accepte les "chown" de la part de l'ancien propriétaire ?

    Du genre, si Alice veut passer un fichier à Bob, elle appelle un programme qui fait un chown si et seulement si l'utilisateur "Alice" se trouve dans le fichier des utilisateurs acceptés de Bob ? Ça me semble éviter les problèmes de quota tout en restant moins lourd que la solution 5.

  • # Pfff

    Posté par  (site web personnel) . Évalué à 3.

    Alice file sa clé USB à bob, qui y recopie les fichiers, ensuite Alice les récupère et les recopie sous son compte.

    On peut aussi passer par une phase d'impression puis de scan + ocr... mais c'est pas bon pour la nature.

    Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

    • [^] # Re: Pfff

      Posté par  . Évalué à 8.

      IL y a encore une autre solution qui est très utilisée, donc je suppose qu'elle est super :

      • Alice ouvre Word un logiciel de traitement de texte
      • Alice copie tout ce qu'elle veut copier (du texte ou des images)¹
      • Alice envoie par pièce jointe son .doc (si hélas elle dépasse les 30Mo fatidiques, il faut appeler la « personne-qui-s'y-connaît-en-informatique »)
      • Bob reçoit le mail et lance son logiciel de traitement de texte
      • Bob peut consulter (parfois) les documents envoyés par Alice

      ¹ : attention, il faut bien passer par la case traitement de texte, certains me diront : mais pour les fichiers qui ne peuvent être dedans ? Eh bien dans ce cas ce sont des fichiers qu'on ne peut pas ouvrir ! donc ils n'ont aucun intérêt.

      207829⁶+118453⁶=193896⁶+38790⁶+14308⁶+99043⁶+175539⁶

      • [^] # Re: Pfff

        Posté par  (site web personnel) . Évalué à 3.

        Alice envoie par pièce jointe son .doc

        Bien-sûr, Alice gagne du temps en utilisant le menu Fichier->Envoyer à au lieu d'ouvrir son logiciel de messagerie Microsoft Outlook.

        Eh bien dans ce cas ce sont des fichiers qu'on ne peut pas ouvrir ! donc ils n'ont aucun intérêt.

        D'ailleurs on peut librement les effacer si on se trouve à court de place sur son disque dur. Astuce supplémentaire: le contenu du dossier C:\ est en principe caché dans l'explorateur de fichiers: cliquez dans la colonne de gauche de l'explorateur pour refaire apparaître ses fichiers et pouvoir libérer plein de place sur votre PC!

    • [^] # Re: Pfff

      Posté par  . Évalué à 3.

      Toi aussi, tu as vécu ça : http://xkcd.com/949/ ?

    • [^] # Re: Pfff

      Posté par  . Évalué à 3.

      On peut aussi passer par une phase d'impression puis de scan

      Aujourd'hui en réunion, mon patron me demande d'imprimer le papier X en A3 couleur. Une fois imprimé, il me demande de le scanner et de l'envoyer à Y à l'étage en dessous.

      Du coup, je lui ai expliqué que oui on peut imprimer en pdf pour l'envoyer et oui on peut merger plusieurs pdf. /o

      True story.

      • [^] # Re: Pfff

        Posté par  (site web personnel) . Évalué à 3.

        Aujourd'hui en réunion, mon patron me demande d'imprimer le papier X en A3 couleur. Une fois imprimé, il me demande de le scanner et de l'envoyer à Y à l'étage en dessous.

        J'ai déjà vu des gens — d'environ mon âge — utiliser une manip' analogue pour insérer une image dans un texte (avec de la colle, donc).

  • # Sat

    Posté par  . Évalué à 6.

    SàT permet d'échanger des fichiers en ligne de commande via le protocole xmpp. En plus le développeur est ici même.

    If you want to copy a file, the syntax is quite similar:
    jp -wg louise
    for reception and:
    jp -g sintel_trailer-480p.ogv pierre
    to send the file

    • [^] # Re: Sat

      Posté par  . Évalué à 1.

      Empathy aussi, et il est intégré à Nautilus : clic droit sur un fichier, Envoyer à, puis choix du contact.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # FileTea

    Posté par  (site web personnel) . Évalué à 2.

    C'est assez pratique et en plus il y a maintenant un paquet debian

    https://filetea.me

    http://blogs.igalia.com/berto/2011/11/10/filetea-now-available-in-debian/

    En gros, on obtient une URL qu'on va partager par courriel à l'autre personne qui récupère le fichier.

    Plutôt que le courriel, on doit pouvoir aussi utiliser le bon vieux talk sous UNIX si on est sur la même machine...

    • [^] # Re: FileTea

      Posté par  . Évalué à 1.

      En gros, on obtient une URL qu'on va partager par courriel à l'autre personne qui récupère le fichier.

      Plutôt que le courriel, on doit pouvoir aussi utiliser le bon vieux talk sous UNIX si on est sur la même machine...

      Merci, j'ai bien ri.

      • [^] # Re: FileTea

        Posté par  (site web personnel) . Évalué à 2.

        Le mercredi 16 novembre 2011 à 15:27 +0100, jiyuu a écrit :
        > Merci, j'ai bien ri.

        write est plus adapté si c'est qu'en local.

      • [^] # Re: FileTea

        Posté par  (Mastodon) . Évalué à 4.

        Ben pourquoi tu rigoles...
        C'est exactement la problématique exposée : les utilisateurs sont tous connectés sur un même serveur, leurs comptes et fichiers dessus.
        Et le problème a résoudre c'est de transmettre un fichier d'un utilisateur à un autre mais bien sur la même machine, avec respect des droits, protection contre les abus etc.

        Tu n'as jamais eu l'occasion de bosser dans ce genre d'environnement où la machine que tu utilises n'est qu'un terminal vers un serveur unique et tout le monde bosse sur le serveur ?
        C'est pourtant assez courant...
        Et je ne crois pas que ça soit drôle, ou alors je n'ai pas compris ce qui te faisait rire.

        Ces gens sont chacun sur leur machine (boîtier+écran+clavier...), mais travaillent tous et sont tous utilisateurs de la même machine (serveur).
        Et franchement, talk c'est plus pratique que le mail on XMPP dans ce genre d'environnement...
        Et si c'est l'utilisation aujourd'hui d'outils ancestraux comme talk qui te font marrer, ben faudra qu'on m'explique la différence fondamentale entre ouvrir un terminal et faire « talk bob », ou lancer son jabber et lui causer dans sa petite fenêtre : on tape du texte des deux côtés, chacun à sa fenêtre, le fait qu'une soit un terminal ne change rien à l'affaire : ça se redimensionne pareil, ça se réduit pareil, ça se ferme pareil...

        Yth.

        • [^] # Re: FileTea

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          C'est parce que ça utilise pas HTTP que c'est has-been ;)

        • [^] # Re: FileTea

          Posté par  . Évalué à 2.

          Bon d'accord. N'ayant que lu la description donnée par Sytoka Modon:

          En gros, on obtient une URL qu'on va partager par courriel à l'autre personne qui récupère le fichier.

          J'ai cru qu'il s'agissait d'installer un serveur web juste pour pouvoir échanger des fichiers. Bien que pratique pour des utilisateurs sur des machines différentes (un peu comme dropbox, dl.free.fr et surement d'autres), je trouvais ça un peu abusé pour des utilisateurs sur la même machine et, dans le même temps, marrant (le http étant encore LA solution). C'était pour ça le : "J'ai bien ri".

          Mais en fait le logiciel présenté, filetea, ne marche pas comme ça (de ce que j'ai compris, c'est basé sur une technologie P2P. Ce n'est pas le serveur qui héberge le fichier. il ne doit faire que le lien entre les pairs) donc mon raisonnement est faux et mon commentaire est à côté de la plaque.

          Sinon, je n'ai rien contre l'utilisation "d'outils ancestraux". J'utilise emacs /o\

          Désolé pour le bruit. Je retourne me cacher dans ma grotte.

          • [^] # Re: FileTea

            Posté par  (Mastodon) . Évalué à 2.

            Bah, moi aussi j'utilise emacs va.
            Mais quand j'essaie de changer, la seule alternative qui se présente est un dérivé de VI, qui est conçu pour ne pas être utilisable, donc bah finalement, je reste sur emacs, et je cherche comment faire ce que je voulais faire avec emacs, ce qui est au final toujours possible (même si j'y comprend fondamentalement rien au fichier de conf d'emacs).

            Yth.

        • [^] # Re: FileTea

          Posté par  . Évalué à 2.

          Oui mais non, le problème de talk, c'est qu'il n'y a pas moyen de l'utiliser en couplage avec un multiplexeur de terminal automatiquement (genre screen ou tmux).

          Du coup tu es dans une application plein écran et là, POP !, ta fenêtre est toute bousillée et tu ne peux plus bosser tant que tu n'as pas arrêté la conversation (et il faudra au passage forcer le redraw de la fenêtre).
          Problème identique avec Write.

          De toute façon la solution à base de .drop est en cours d'implémentation. On en est à la phase de test avec des volontaires. On partagera les scripts dès qu'on jugea que le résultat sera atteint.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.