2 votes

Comment faire passer un fichier d'un utilisateur à l'autre (sans en créer de copie) ?

Supposons que l'utilisateur "qqq" possède le fichier /home/qqq/bigfile.dat et qu'il veuille le transmettre à l'utilisateur "aaa" sans l'aide de root (il doit appartenir à "aaa"). Que doivent faire les utilisateurs "qqq" et "aaa" ?

De manière naïve :

  1. uid=qqq$ mv bigfile.dat /home/aaa/
  2. uid=aaa$ chown aaa /home/aaa/bigfile.dat # Operation not permitted

Bien entendu, il est possible d'utiliser des listes de contrôle d'accès (ACL) ( uid=qqq$ setfacl u:aaa:rw- /home/aaa/bigfile.dat ) ou en faisant une copie temporaire ( uid=aaa$ mv bigfile.dat bigfile.dat_ && cat bigfile.dat_ > bigfile.dat && rm bigfile.dat_ ), mais les deux méthodes semblent présenter des inconvénients.

Les deux utilisateurs acceptent (en émettant une commande) de "passer" le fichier. Cette opération doit être rapide, en préservant l'inode et les autres attributs, etc.

Comment le faire proprement ?

1voto

Les anciens systèmes Unix permettaient à n'importe quel utilisateur d'attribuer à n'importe quelle cible le droit d'accès à ses propres fichiers. La plupart ne le font plus, car cela a créé des problèmes de sécurité :

  • Si des quotas d'utilisation du disque sont en place, l'utilisateur A pourrait stocker des fichiers aux frais de l'utilisateur B en les plaçant dans un répertoire privé. L'utilisateur B ne le saurait jamais, sauf en comparant son utilisation visible du disque avec ses quotas, et n'aurait aucun moyen de trouver le voleur de quotas.

  • Certains programmes privilégiés (exécutables ou démons set[ug]id) supposent que si un fichier appartient à un utilisateur, celui-ci en a approuvé le contenu. Si l'utilisateur A pouvait attribuer un fichier à l'utilisateur B, A pourrait tromper le programme privilégié en lui faisant accepter n'importe quelle donnée. (Il s'agit de toute façon d'une conception peu sûre, car même si A a réellement écrit le fichier, il peut ne pas l'avoir approuvé pour cet usage particulier ; mais de tels programmes existent, et le fait d'interdire les chowns réduit les risques).

  • Un chown effectué par un utilisateur non root ne peut pas être annulé. C'est un risque que vous pouvez accepter (et en fait, il y a d'autres choses que vous pouvez faire sur un système de fichiers Unix qui ne peuvent être annulées que si un autre utilisateur coopère).

Pour autant que je sache, il est impossible de modifier la propriété d'un fichier sur la plupart des systèmes Unix modernes sans la coopération de root. Root pourrait effectuer le chown ou donner à A ou B la permission de le faire via sudo, mais cela nécessite une intervention plus ciblée de la part de Root que ce qui est généralement souhaitable.

Si les ACL sont activées, comme vous l'avez remarqué, cela donne la plupart des effets pratiques du chowning.

Si le flux de travail exige vraiment que A soit le propriétaire à un moment donné et que B soit le propriétaire à un autre moment, il existe d'autres options que vous pouvez explorer.

  • B peut utiliser pied de biche pour exécuter un programme et lui faire croire qu'il s'exécute en tant que root, ce qui permet de simuler un chown qui n'existe que dans la mémoire de fakeroot ( fakeroot sh -c 'chown B file; su B -c program' ).

  • Vous pourriez jouer des tours à FUSE. Par exemple bindfs vous permet de créer une vue de l'arborescence d'un répertoire où les fichiers ont un propriétaire différent ( mkdir view_for_B; bindfs -u B actual_directory view_for_B ).

0voto

chris Points 10694

Pouvez-vous déplacer le fichier vers un espace partagé auquel les deux utilisateurs ont accès en écriture (ou ce genre de chose n'existe-t-il pas sous Linux ?), puis demander au propriétaire d'attribuer un chmod au destinataire ?

Mon état d'esprit est ancré dans Mac OS X, ce qui peut ou non vous convenir.

0voto

Brad Points 11

Cela dépend de ce que vous entendez par "sans aide de la racine". Si vous pouvez demander à root d'ajouter aaa et qqq à un nouveau groupe (n'importe quel nom fera l'affaire) et de s'assurer que le fichier a au moins r-- perms pour le nouveau groupe... (il peut conserver rwx pour l'utilisateur aaa - vous obtenez donc => aaa:newgroup rw-r----- ) alors sans AUTRE aide de root, aaa peut modifier et qqq peut lire le même fichier.

Si vous voulez le faire "à l'encontre des souhaits de root", alors je considérerais que c'est un bogue si vous trouviez un moyen qui fonctionne. On a beaucoup réfléchi pour empêcher cela car c'est un problème de sécurité si aaa peut mettre un cheval de Troie dans un répertoire auquel qqq a accès et qui pourrait être exécuté "accidentellement".

-1voto

Janne Pikkarainen Points 7357

Une façon de procéder consisterait à créer une clé ssh qui permettrait à l'utilisateur qqq pour se connecter en tant que aaa . Comme qqq faire

ssh-keygen -t rsa

et décidez si vous voulez opter pour une clé sans mot de passe ou non.

Ajoutez ensuite la clé nouvellement créée à aaa en l'exécutant en tant que qqq :

ssh-copy-id -i ~/.ssh/id_rsa.pub aaa@localhost

Ensuite, vous pouvez déplacer les fichiers comme suit :

scp bigfile.dat aaa@localhost:

(ou avec votre client sftp préféré)

De cette façon, sshd se chargera de changer la propriété.

L'utilisation de scp/sftp pour le transfert local peut sembler étrange, mais au moins cela fonctionne ! :)

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X