• # Une astuce bien utile mais déception

    Posté par . Évalué à 10 (+8/-0).

    Je lis souvent avec beaucoup d’intérêt ses articles mais là je suis un peu déçue 😛

    Pourquoi faire appel à chatGPT alors que la réponse était accessible dès la première page de recherche sur DDG :

    https://www.baeldung.com/linux/symlinks-permissions

    • [^] # Re: Une astuce bien utile mais déception

      Posté par (site web personnel, Mastodon) . Évalué à 10 (+15/-0).

      Le ténia de l'IA l'a atteint lui aussi. Il fait tomber tous les idoles du numériques comme des mouches.

      (avant que vous ne moinssiez : oui, je déplore que Bortzmeyer fasse la pub de ChatGPT dans son blog et sur son Mastodon, je déplore que nombre de gens comme lui, censés être plus malins que ça, s'avèrent ne pas l'être, et j'ai bien conscience que les end-users ne sont pas la partie la plus problématique du problème, même si leur statut de personnalité publique justifie qu'on ait certaines exigences à leur égard)

  • # Il manque un avertissement

    Posté par . Évalué à 6 (+4/-0).

    Ici ça fonctionne via le groupe bob et le chmod g+w, mais rien ne garanti que ce groupe ne contient que l'utilisateur bob. Sur un répertoire qui aurait des droits comme bob:users, ça donnerait une catastrophe. L'article pourrait le préciser.

    • [^] # Re: Il manque un avertissement

      Posté par . Évalué à 3 (+1/-0).

      Peux-tu expliquer en quoi cela donnerait une catastrophe ?

      • [^] # Re: Il manque un avertissement

        Posté par . Évalué à 4 (+2/-0). Dernière modification le 13 septembre 2026 à 11:21.

        Ah oui, pardon, je suis coupable de ce que je pointe du doigt :).

        Le fait de changer les permissions du répertoire personnel pour laisser le groupe y écrire, fait que si tu ne contrôles pas les membres de ce groupe, peut amener à laisser d'autres comptes écrire dans le répertoire personnel.

        Ici la première ligne part du principe que le groupe bob ne contient que l'utilisateur bob.

        $ sudo chown root:bob .
        $ sudo chmod g+w .
        

        C'est une convention, mais pas du tout une obligation. Si plus tard, tu décides que finalement, les répertoires personnels doivent appartenir à users, tu ouvres une brèche. Si pour une raison ou une autre, le gid du groupe est réutilisé pour un autre compte, tu ouvres une brèche.

        Bref, c'est le g+w qui est problématique. Je me dis que résoudre le problème de "empêcher une personne de modifier un fichier dans son répertoire personnel" en mettant des permissions un peu piégeuses sur ledit répertoire n'en vaut pas forcément la chandelle.

        Après, sur le fond, la question soulevée au départ par Stéphane est intéressante.

        • [^] # Re: Il manque un avertissement

          Posté par . Évalué à 4 (+2/-0).

          Le fait de changer les permissions du répertoire personnel pour laisser le groupe y écrire, fait que si tu ne contrôles pas les membres de ce groupe, peut amener à laisser d'autres comptes écrire dans le répertoire personnel.

          Oui mais c'est bien ce qui est recherché et le problème vient alors d'une mauvaise gestion des utilisateurs/groupes pas des commandes proposées.

          Du fait du sticky bit si (削除) alice (削除ここまで) membre du groupe bob peut écrire dans ledit répertoire, elle ne pourra pas agir sur les fichiers appartenant à bob. Et si l'administrateur à mis alice dans le groupe bob, c'est bien parce qu'il veut lui permettre d’accéder à certains contenus appartenant à bob.
          On est très loin de la « catastrophe ».

          • [^] # Re: Il manque un avertissement

            Posté par . Évalué à 2 (+0/-0).

            C'est vrai, d'autant qu'il semble qu'avoir le droit d'écrire dans le répertoire ne suffit pas pour y supprimer des fichiers.

            • [^] # Re: Il manque un avertissement

              Posté par . Évalué à 6 (+4/-0).

              Avoir le droit d'écriture sur un répertoire permet d'y créer, renommer et supprimer des fichiers. Tel quel, oui cela peut être une catastrophe.

              Encore une fois c'est l'utilisation du sticky bit qui évite cela: l’utilisateur ne peut alors agir que sur ses propres fichiers (voir le répertoire /tmp) qui fonctionne comme cela

Envoyer un commentaire

Suivre le flux des commentaires

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