web-dev-qa-db-fra.com

Dossier de partage avec VM via libvirt, 9p, autorisation refusée

Un hôte Ubuntu Server 14.04 héberge un invité Ubuntu Server 14.04 via libvirt/qemu-kvm. Le système fonctionne bien, mais en tant qu'invité, j'ai des problèmes pour écrire dans un dossier partagé (<filesystem>) qui me rend fou. Les deux machines sont des installations relatives de vanille.

J'ai attaché le dossier donné comme ceci:

[Host] $ virsh edit guest-vm-name
# ...
<filesystem type='mount' accessmode='mapped'>
  <source dir='/data'/>
  <target dir='/data'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</filesystem>
# ...

À partir de l'invité, je monte le système de fichiers comme suit:

[guest] $ Sudo -u www-data mkdir /tmp/mnt
[guest] $ Sudo mount -t 9p -otrans=virtio,rw,version=9p2000.L /data /tmp/mnt

J'utilise l'utilisateur www-data, car ce sera l'utilisateur effectif plus tard, et les identifiants de groupe et d'utilisateur doivent correspondre si vous utilisez p9, afaiu. Cela signifie également que sur l'hôte,/data (qui est une partition ext4, LVM sur RAID btw) ressemble à

[Host] $ ls -lha /data
[Host] $ drwxrwxr-x  4 www-data www-data 4.0K Nov 11 08:34 .
[Host] $ drwxr-xr-x 24 root     root     4.0K Nov  7 16:58 ..
[Host] $ drwxr-xr-x  2 www-data www-data 4.0K Nov 11 08:34 jail
# ...

Sur l'invité, si j'essaie d'écrire sur un élément du système de fichiers partagé, des erreurs d'autorisation se produisent (quel que soit l'utilisateur utilisé):

[guest] $ Sudo -u www-data touch /tmp/mnt/jail/letmeout
touch: cannot touch ‘/tmp/mnt/jail/letmeout’: Permission denied

Je peux lire des fichiers si

[guest] $ cat /tmp/mnt/jail/throughthewindow
Great Weather!

J'ai essayé diverses choses, notamment:

  • arrêté le service d'apparmeur et appelé aa-plaindre (j'espère que c'était efficace)
  • définir la sécurité sur none dans /etc/libvirt/qemu.conf
  • définir l'utilisateur et le groupe sur root dans /etc/libvirt/qemu.conf

/ var/log/syslog et dmesg ne montrent rien de suspect.

Des pointeurs?! Merci.

serverpermissionsvirtualizationqemu
7
Felix

Je sais que c’est un vieux fil, mais je viens de rencontrer un problème similaire et de trouver une solution qui fonctionne au moins en partie .

J'ai également changé les valeurs d'utilisateur et de groupe dans /etc/libvirt/qemu.conf en root, comme vous l'avez fait.
Mais j'ai aussi changé le paramètre dynamic_ownership, car la description semblait prometteuse:

# Si libvirt doit changer dynamiquement la propriété du fichier
# pour correspondre à l'utilisateur/groupe configuré ci-dessus. La valeur par défaut est 1.
# Réglez sur 0 pour désactiver les modifications de propriété de fichier.

Ma configuration est:

  • Hôte: Debian 8 (Jessie)
  • Invité: Debian 8 (Jessie)
  • le dossier partagé sur l'hôte appartient à rootname__
  • l'utilisateur local w/id 1000 est membre du groupe libvirt(peut être important)
  • le point de montage sur l'invité (/mnt/data) appartient à l'utilisateur 1000 ("alexander").

Je peux enfin écrire des fichiers dans le dossier partagé monté avec à la fois root (0) et alexander (1000). (auparavant, seul root était autorisé à écrire des fichiers ici)

Régler dynamic_ownership sur 0 est ce qui doit être fait dans le mode d'accès "mappé".

Voici quelques informations supplémentaires sur ma configuration:

/etc/libvirt/qemu.conf:

user = "root"
group = "root"
dynamic_ownership = 0

système de fichiers (virsh edit):

<!-- ... -->
    <filesystem type='mount' accessmode='mapped'>
      <source dir='/share/vm.localdomain/owncloud_data'/>
      <target dir='/data'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
    </filesystem>
<!-- ... -->

Hôte:

ls -al /share/vm.localdomain/owncloud_data/
total 8
drwxr-xr-x 2 root      root      4096 Sep  8 00:15 .
drwxr-xr-x 7 root      root      4096 Sep  8 00:10 ..

fstab sur l'invité:

/data  /mnt/data/  9p  trans=virtio  0  0

Client:

root@debian:~# cd /mnt/data
root@debian:/mnt/data# touch touched_by_root
root@debian:/mnt/data# su - alexander
alexander@debian:~$ cd /mnt/data
alexander@debian:/mnt/data$ touch touched_by_user
alexander@debian:/mnt/data$ ls -al
total 16
drwxr-xr-x 2 alexander alexander 4096 Sep  8 00:30 .
drwxr-xr-x 6 root      root      4096 Sep  7 18:13 ..
-rw-r--r-- 1 root      root         0 Sep  8 00:30 touched_by_root
-rw-r--r-- 1 alexander alexander    0 Sep  8 00:30 touched_by_user

retour sur l'hôte:

root@Host /share/vm.localdomain # ls -al /share/vm.localdomain/owncloud_data/
total 16
drwxr-xr-x 2 root      root         4096 Sep  8 00:30 .
drwxr-xr-x 7 root      root         4096 Sep  8 00:10 ..
-rw------- 1 root      libvirt-qemu    0 Sep  8 00:30 touched_by_root
-rw------- 1 root      libvirt-qemu    0 Sep  8 00:30 touched_by_user

conclusion

Ce qui est étrange, c’est que sur l’invité, ces deux fichiers appartiennent à des utilisateurs différents (root et alexander), alors que sur l’hôte, les deux fichiers appartiennent au même utilisateur (root: libvirt-qemu). : -O
Je ne sais pas exactement comment cette magie fonctionne , mais apparemment, c'est le cas.

J'espère que cela t'aides,
Alexandre

5
Alexander

@ Alexandre a donné une excellente réponse. Je n'ai pas fait tout ce qu'il a fait, mais c'est ce que j'ai fait pour obtenir les droits du même utilisateur fonctionnant dans les deux sens sur le système de fichiers 9p. (Cette méthode a pour but de faire en sorte que 9p fonctionne dans les deux sens, sans aucun problème de sécurité. Pour plus de sécurité, vous aurez besoin d’une méthode ou de paramètres différents.)

Host (l'ordre n'a pas d'importance)

  • J'ai ajouté mon utilisateur hôte au groupe suivant: < kvm > (Je suis également membre de < libvirtd >). Cette étape peut être inutile car:

  • dans le fichier /etc/libvirt/qemu.conf , vous pouvez modifier l'utilisateur et le groupe avec lesquels toutes vos VM s'authentifient et s'exécutent.

( c'est un puissant petit changement, et les répercussions doivent être cartographiées si vous essayez d'accomplir cela sur quelque chose comme un serveur de production )

user = "billy"    #### No, my name isn't billy, but it's cute. 
                  #### Alternatively you can declare your <uid>, like
                  ## user = "+1000" ####        << That's what I did.
                  #### (They tell you everything you need to know about
                  #### this stuff inside /etc/libvirt/qemu.conf)
group = "billy"
dynamic_ownership = 1

(La modification ci-dessus indique à l'hôte de la machine virtuelle de convertir toutes les requêtes libvirt entre ordinateurs virtuels de tous les ordinateurs virtuels invités que vous exécutez vers l'utilisateur < > que vous définissez, y compris guest-VM < racine >. * Remarque encore une fois qu'il s'agit d'un paramètre système concernant libvirt et par extension qemu if libvirt est votre unique interface qemu .)

(à propos, "Squash" fait référence à un modèle de sécurité 9p. Il signifie "aucun" et constitue le paramètre le plus permissif pour ce contexte)

GUEST

(J'ai également ajouté une option, comme expliqué dans le document ci-dessous) Ma commande de montage est la suivante:

mount -t 9p -o trans=virtio,access=any,version=9p2000.L /hostshare /tmp/Host_files

Nore que si vous n'avez pas la permission d'écrire sur le partage ou une permission limitée après l'avoir configurée, l'excellente suggestion de la réponse de @randomocean devrait vous aider. C'est-à-dire que vous devez < root > créer un dossier sous le partage et y définir chmod 777.

-Even Plus d'infos: https://wiki.qemu.org/Documentation/9psetup

1
Hypocritus

J'ai également eu ce problème, j'ai créé un dossier nommé /home/user/shared sur l'hôte, puis utilisé virt-manager pour l'ajouter et l'a monté en tant que virtio 9p sur la machine virtuelle qemu.

J'ai vérifié les paramètres dans /etc/apparmor.d/libvirt et il contient des entrées pour le nouveau /home/user/shared, et j'ai remarqué qu'il ne disposait que de l'autorisation 'r' pour /home/user/shared, mais qu'il y avait rw pour tous les fichiers de /home/user/shared/. J'ai essayé d'ajouter un w pour les autorisations d'écriture, mais cela ne semblait pas avoir été enregistré. Je me suis donc rendu dans l'hôte /home/user/shared, j'ai créé un sous-répertoire et effectué un chmod 777 sur ce sous-répertoire. Cela a fonctionné et l'invité VM a pu écrire au directeur su tous les fichiers créés et édités.

tldr: créez un sous-répertoire dans le dossier partagé avec les autorisations 777 et voyez si vous pouvez écrire dans celui-ci.

1
randomocean