Journal Petit Probléme de Permission

Posté par  .
Étiquettes : aucune
0
20
mai
2004
Cher Journal

je ne comprends pas, pourquoi je ne peux pas virer le fichier qui est dans $HOME./enlightenment/ et qui s'appelle user_themes.cfg même avec root ?

C'est un probléme de quotas ?
  • # Heu tu peux préciser ?

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

    Pour les quotas : non, il n'y a pas de quotas de suppression.
    Pour le problème: aucune idée vu que tu dis pas le problème, l'erreur, ...
    Présenté comme ca je pourrais te répondre «parce que tu n'as pas du penser à taper rm $HOME/enlightenment/user_themes.cfg»...
    • [^] # Re: Heu tu peux préciser ?

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

      J'ai déjà eu le cas, une fois, sur des machines de la fac, d'un fichier dont j'étais propriétaire et que je n'arrivais pas à effacer (étant propriétaire, je me suis pourtant assuré d'avoir les bons droits)... jamais pu trouver d'où ça venait ni réussi à le reproduire, je ne dois pas être doué.
      • [^] # Re: Heu tu peux préciser ?

        Posté par  . Évalué à 6.

        Pour supprimer un fichier, ce ne sont pas les droits sur le fichier qui sont important, mais les droits sur le répertoire qui le contient.
        En effet, si tu as les droits d'écriture sur un répertoire, tu peux en supprimer les fichiers même si tu n'a pas le droit de les modifier.
        Donc ce sont les permissions du répertoire qui contient le fichier qu'il faut vérifier.
        • [^] # Re: Heu tu peux préciser ?

          Posté par  . Évalué à 1.

          C'est vrai qu'il faut faire très attention avec ça, car le problème peut aussi arriver dans l'autre sens.
          On pense qu'un fichier est protégé, et boom, plus de fichier (ça sent le vécu, c'est normal).
          Quelqu'un sait-il d'ailleur le pourquoi de ceci. Je trouve ça en effet étrange comme principe. Est-ce une contraite technique, ou alors cela semblait logique lors de la conception des systèmes de fichiers.
          De plus, est-il possible de protéger des fichiers contre l'effacement, mais pas ses voisins (ceux qui sont dans le même dossier).
          • [^] # Re: Heu tu peux préciser ?

            Posté par  . Évalué à 3.

            C'est une conséquence de l'inplémentation du système.
            Créer (lier, link) ou supprimer (délier, unlink) un fichier se fait dans le répertoire, on ajoute un fichier au répertoire et c'est bien ce dernier qui est modifié.

            De plus, est-il possible de protéger des fichiers contre l'effacement, mais pas ses voisins (ceux qui sont dans le même dossier).

            C'est à ça que sert le sticky bit sur les répertoires (pour les fichiers il est obsolète), extrait de la manpage de chmod:

            "When the sticky bit is set on a directory, files in that directory may be unlinked or renamed only by root or their owner. Without the sticky bit, anyone able to write to the directory can delete or rename files. The sticky bit is commonly found on directories, such as /tmp, that are world-writable."

            Faut pas trop t'inquiéter, Unix a des dizaines d'années d'expériences derrière lui, part du principe qu'il y a déjà un moyen de régler les problèmes que tu rencontre et cherche-les, souvent la réponse n'est pas si loin que ça ;-)
    • [^] # Re: Heu tu peux préciser ?

      Posté par  . Évalué à 2.

      où alors parce que le fichier est peut-être dans $HOME/.enlightenment/ et pas dans $HOME./enlightenment/, vérifie la posistion du "."
  • # LOL

    Posté par  . Évalué à -4.

    lol, je crois qu'il n'y a pas beaucoup d'autres commandes pour supprimer des fichiers que rm !
    • [^] # Re: LOL

      Posté par  . Évalué à 2.

      mv fichier /dev/null ?
  • # miaou

    Posté par  . Évalué à 8.

    man chattr
    l'option +s/-s peut etre.
    verifie je me rappelle plus.
    (et sur linuxfr.org il y a aussi des forums...)

Suivre le flux des commentaires

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