Compartilhando pasta com VM através de libvirt, 9p, permissão negada

Question

Um host do Ubuntu Server 14.04 hospeda um convidado do Ubuntu Server 14.04 via libvirt / qemu-kvm. O sistema roda bem, mas - como convidado - tenho problemas para gravar em uma pasta compartilhada ( <filesystem> ) que me deixa louco. Ambas as máquinas são instalações relativas de baunilha.

Eu anexei a pasta dada assim:

[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>
# ...

Do convidado, montei o sistema de arquivos da seguinte forma:

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

Eu uso o usuário www-data , já que esse será o usuário efetivo mais tarde, e ids de grupo e usuário precisam corresponder se p9 for usado, afaiu. Isso também significa que no host, / data (que é partição ext4, LVM em RAID btw) se parece com

[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
# ...

No guest, se eu tentar gravar qualquer coisa no sistema de arquivos compartilhado, obtenho erros de permissão (independentemente do usuário usado):

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

Eu posso ler arquivos embora

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

Eu tentei várias coisas, especialmente:

• parou o serviço apparmor e chamou aa-reclamar (espero que tenha sido eficaz)
• defina a segurança como nenhum em /etc/libvirt/qemu.conf
• definir usuário e grupo para raiz em /etc/libvirt/qemu.conf

/ var / log / syslog e dmesg não mostram nada suspeito.

Quaisquer ponteiros ?! Obrigado.

    

Answer 1

Eu sei que este é um segmento antigo, mas acabei de encontrar um problema semelhante e encontrei uma solução que funciona pelo menos em partes .

Eu também alterei os valores de usuário e grupo em /etc/libvirt/qemu.conf para root , como você fez.
Mas também alterei a dynamic_ownership configuração , porque a descrição parecia promissora:

% bl0ck_qu0te%

Minha configuração é:

• Anfitrião: Debian 8 (Jessie)
• Convidado: Debian 8 (Jessie)
• a pasta compartilhada no host pertence a root
• usuário local w / id 1000 é membro do grupo libvirt (pode ser importante)
• ponto de montagem no convidado ( /mnt/data ) pertence ao usuário 1000 ("alexander")

Agora posso escrever arquivos na pasta compartilhada montada com ambos root (0) e alexander (1000). (antes de fazer isso, apenas o root tinha permissão para gravar arquivos aqui)

A configuração de dynamic_ownership para 0 é o que deve ser feito no modo de acesso "mapeado".

Veja mais algumas informações sobre minha configuração:

/etc/libvirt/qemu.conf:

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

sistema de arquivos (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>
<!-- ... -->

Anfitrião:

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 no convidado:

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

Convidado:

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

de volta ao host:

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

conclusão

O mais estranho é que no guest esses dois arquivos pertencem a usuários diferentes (root vs. alexander), enquanto que no host, ambos os arquivos pertencem ao mesmo usuário (root: libvirt-qemu). : -O
Eu não sei exatamente como essa mágica funciona, mas parece que sim.

Espero que isso ajude,
Alexandre

    

Answer 2

Eu também tive esse problema, criei uma pasta chamada /home/user/shared no host e usei o virt-manager para adicionar a pasta e montá-la como um virtio 9p na VM do qemu.

Eu verifiquei as configurações em /etc/apparmor.d/libvirt e ele tem entradas para o novo /home/user/shared, e notei que ele tinha apenas a permissão ' r ' para /home/user/shared , mas ele tem rw para todos os arquivos em /home/user/shared/ . Eu tentei adicionar um w para permissões de gravação, mas isso não parece ser salvo, então entrei no host /home/user/shared e criei um subdiretório e fiz um chmod 777 nesse subdiretório. Isso funcionou e a VM convidada conseguiu escrever para o su director qualquer criação e edição de arquivos.

tldr: crie um subdiretório na pasta compartilhada com 777 permissões e veja se você pode escrever para isso.

    

Answer 3

@Alexander deu uma ótima resposta. Eu não fiz tudo o que ele fez, mas isso é o que eu fiz para obter direitos de mesmo usuário trabalhando nos dois lados do sistema de arquivos 9p. (Desta forma, pretende-se apenas fazer com que o 9p funcione, em ambos os sentidos, sem dificuldades de segurança. Para mais segurança, você precisará de um método ou configurações diferentes)

HOST (a ordem não é importante)

• Eu adicionei meu usuário do host ao seguinte grupo: < kvm > (Eu também sou membro da < libvirtd >). Este passo pode ser desnecessário porque:

• no arquivo /etc/libvirt/qemu.conf você pode alterar o usuário e o grupo com os quais todas as suas VMs são autenticadas e executadas.

( essa é uma pequena alteração poderosa , e as repercussões precisam ser mapeadas se você estiver tentando realizar isso em algo como um servidor de produção )

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

(O que a alteração acima faz é dizer ao host da máquina virtual para converter todas as solicitações de MVs de libvirt para qualquer VM guest que você estiver executando para o usuário > que você definir; incluindo guest-VM < raiz & gt ;. * Note novamente que é uma configuração de todo o sistema com relação a libvirt e por extensão qemu se libvirt for sua única interface qemu .

• Configuração que você hospeda como encontrada neste excelente documento oficial link

(a propósito, "Squash" faz referência a um modelo de segurança 9p. Significa "none" e é a configuração mais permissiva para esse contexto)

CONVIDADO

• Dentro da VM guest, monte o compartilhamento 9p usando < root > privilégios, também encontrados na parte inferior do documento link

(Eu também adicionei uma opção como explicado no documento abaixo) Meu comando de montagem é:

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

Nore que, se você não tiver permissão para escrever para o compartilhamento ou tiver permissão limitada depois de configurá-lo, a excelente sugestão da resposta de @randomocean deverá ajudar. Ou seja, tem < raiz > crie uma pasta sob o compartilhamento e defina chmod 777 para ela.

-Mais Informativo: link