2 votes

Le bit collant sur /tmp ne fait pas ce qu'il est censé faire ?

Je lance fréquemment un script qui crée trois fichiers dans /tmp puis les déplace dans le répertoire de destination. J'étais perplexe devant les messages d'erreur:

mv: ./20170608-l.gpx : définir propriétaire/groupe (était : 503/0) : Opération non permise
mv: ./20170608-u.gpx : définir propriétaire/groupe (était : 503/0) : Opération non permise
mv: ./20170608.csv : définir propriétaire/groupe (était : 503/0) : Opération non permise

Le script n'utilise pas sudo, donc le groupe wheel (zéro) semblait étrange. En vérifiant /tmp (/private/tmp), j'ai vu que le bit collant était activé. Mais forcer le groupe à être wheel (ce que je m'attendais à ce qu'il fasse) n'est pas ce que dit Wikipedia (citante une page man de Leopard). Et m'empêcher de changer le groupe sur la copie non plus. La copie finit avec le même propriétaire—moi—et mon groupe—staff—donc en fait il a bien fait ce qu'il disait ne pas permettre.

Je peux comprendre la logique de ce que dit la page man, mais pourquoi le message d'erreur dit que quelque chose de différent n'était pas autorisé quand en fait c'est exactement ce qui s'est passé ? Et pourquoi les fichiers dans /tmp sont créés avec le groupe wheel alors que ce n'est pas ce que le bit collant est censé faire ?

/tmp est racine/wheel comme prévu,

WGroleau@MBP ~ % ls -latde@ /private/tmp
drwxrwxrwt  7 root  wheel  224 Dec 21 09:58 /private/tmp

mais le document mentionné déclare que le bit collant empêche la suppression par quelqu'un d'autre que le propriétaire. Comme j'étais le propriétaire, cela n'a pas d'importance. Mais cela ne dit pas ce que je pensais qu'il voulait dire, à savoir annuler le groupe du créateur. Cependant, c'est bien ce qui s'est produit. Et ensuite le message d'erreur indique faussement qu'il n'a pas pu changer le groupe en le mien. Pas sûr si changer le groupe est requis quand la destination n'a pas de bit collant :

_WGroleau@MBP ~ % ls -late@d /Volumes/Sidecar/Sort_By_Date/2017/06/08 drwxrwxr-x 16 WGroleau staff 512 Dec 20 23:35 /Volumes/Sidecar/Sort_ByDate/2017/06/08

4voto

nohillside Points 82672

Le code source pour mv est disponible sur Github, la partie concernant l'erreur se trouve à la ligne 448.

oldmode = sbp->st_mode & ALLPERMS;
if (fchown(to_fd, sbp->st_uid, sbp->st_gid)) {
    warn("%s: set owner/group (was: %lu/%lu)", to, (u_long)sbp->st_uid, (u_long)sbp->st_gid);
    if (oldmode & (S_ISUID | S_ISGID)) {
        warnx("%s: owner/group changed; clearing suid/sgid (mode was 0%03o)", to, oldmode);
        sbp->st_mode &= ~(S_ISUID | S_ISGID);
    }
}

Ce qui se passe réellement au sein de mv est le suivant:

  • Comme il s'agit d'un fichier ordinaire déplacé vers un autre système de fichiers, la commande ne peut pas utiliser l'appel système standard rename() mais utilise une fonction interne pour créer un nouveau fichier sur le système de fichiers cible, copier le contenu et puis supprimer le fichier source
  • Initialement le fichier cible est créé avec le groupe par défaut de l'utilisateur (généralement staff)
  • Après la copie, la commande essaie d'appliquer le propriétaire et le groupe du fichier source au nouveau fichier cible créé (l'appel fchown() à la deuxième ligne de l'extrait de code ci-dessus
  • Les fichiers dans /tmp appartiennent au groupe wheel mais les utilisateurs normaux ne font pas partie de ce groupe, donc fchown() échoue, entraînant le message d'avertissement.

Cela signifie également que sudo mv /tmp/foo /Volumes/External/ réussira sans avertissement:

$ touch /tmp/foo
$ mv /tmp/foo /Volumes/EXT
mv: /Volumes/EXT/foo: set owner/group (was: 502/0): Operation not permitted
$ touch /tmp/foo
$ sudo mv /tmp/foo /Volumes/EXT
$

3voto

Jose Chavez Points 645

Votre question découle d'une incompréhension concernant le fait que les fichiers ont le groupe wheel - cela n'a en réalité rien à voir avec le bit collant.

Le bit collant fonctionne comme prévu - et fait ce qu'il a toujours fait. Il n'y a pas de traitement spécial pour le dossier /tmp à cet égard.

En général, un utilisateur ayant des permissions d'écriture et d'exécution pour un répertoire est autorisé à renommer et supprimer des fichiers dans ce répertoire. Comme vous pouvez le voir dans votre copie, tous les autres ont des permissions d'écriture et d'exécution sur le dossier /tmp. Cela crée le problème que n'importe quel utilisateur peut supprimer les fichiers temporaires des autres utilisateurs. Ce n'est pas souhaitable.

Le bit collant résout ce problème en déclarant au système que vous ne souhaitez pas les règles habituelles des permissions de répertoire. Seul le propriétaire du fichier, le propriétaire du dossier /tmp ou l'utilisateur root peuvent renommer et supprimer des fichiers dans /tmp.

C'est donc le bit collant - rien dans cette explication ne mentionne le groupe wheel.

Cela découle d'un fait de base concernant les permissions du système de fichiers sur les systèmes de type Unix, comme par exemple macOS. Lorsque vous créez un fichier sur ces systèmes, le groupe du nouveau fichier est par défaut le groupe du dossier dans lequel le fichier est créé. Comme le dossier /tmp a le groupe wheel, les nouveaux fichiers créés dans le dossier /tmp auront par défaut le groupe wheel.

Lorsque vous essayez ultérieurement de déplacer des fichiers de /tmp vers d'autres systèmes de fichiers, le programme mv va essayer de faire en sorte que le fichier de destination ait le même propriétaire et groupe que le fichier original. Cela échoue car vous ne pouvez pas définir le groupe du nouveau fichier en wheel - à la place, le fichier finit par avoir le groupe par défaut - à savoir le groupe du dossier où le fichier est créé.

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X