Permissões de usuário dentro e fora dos contêineres LXC?

Estou executando alguns serviços dentro dos contêineres do Docker LXC no meu servidor e estou começando a realmente fazer coisas sérias com eles.

Uma coisa que não estou claro é como as permissões de usuário funcionam dentro e fora do contêiner. Se, por exemplo, estou executando o MySQL em um contêiner e tiver seu diretório de dados definido /datacomo volume do Docker, como as permissões dentro e fora do contêiner afetam as políticas de acesso?

Obviamente, a idéia é executar o MySQL como seu próprio usuário no container (ie mysql:mysql) e conceder direitos de leitura e gravação a esse diretório. Suponho que isso seria bastante simples, apenas chmodno diretório etc. Mas como isso funciona fora do contêiner? Agora que tenho esse volume compartilhado do Docker chamado 'dados', como faço para gerenciar o controle de acesso a ele?

Estou procurando especificamente executar um usuário sem privilégios fora do contêiner do Docker, que acessará periodicamente o volume compartilhado do MySQL e fará backup dos dados.

Como posso configurar permissões, usuários e grupos para que um usuário específico no host possa ler / gravar arquivos e pastas no volume compartilhado do Docker?

Desde o lançamento do 0.9, o Docker caiu LXCe usa seu próprio ambiente de execução libcontainer,. Sua pergunta é um pouco antiga, mas acho que minha resposta ainda se aplica à versão que você está usando.

Resposta rápida: Para entender as permissões de volumes, você pode usar a analogia de mount --bind Host-Dir Container-Dir. Portanto, para atender aos seus requisitos, você pode usar qualquer método tradicional para gerenciar permissões. Eu acho que o ACL é o que você precisa .

Resposta longa: Assim como no seu exemplo, temos um contêiner chamado dock com um volume /data.

docker run -tid --name dock -v /usr/container/Databases/:/data \
    centos:latest /bin/bash

Dentro do contêiner, nosso servidor MySQL foi configurado para usar o /datacomo seu diretório de dados. Portanto, temos nossos bancos de dados /datadentro do contêiner. E fora do recipiente no sistema operacional hospedeiro, temos montado esse /datavolume a partir /usr/container/Databases/e nós atribuir um usuário normal bob para fazer backups dos bancos de dados. Na máquina host, configuraremos as ACLs para o usuário bob .

useradd -u 3000 bob
usermod -R o=--- /usr/container/Databases/
setfacl -R -m u:bob:rwx /usr/container/Databases/
setfacl -R -d -m u:bob:rwx /usr/container/Databases/

Para testá-lo, vamos fazer um backup com o usuário bob .

su - bob
tar -cvf container-data.tar /usr/container/Databases/

E o tar será listado e você poderá ver que nosso usuário conseguiu acessar todos os arquivos.

Agora, de dentro do contêiner, se você verificar getfacl, notará que, em vez de bob, ele mostra 3000. Isso ocorre porque o UID do bob é 3000 e não existe esse usuário no contêiner, então ele simplesmente exibe o UID que recebe dos metadados . Agora, se você criar um usuário em seu contêiner useradd -u 3000 bob, notará que agora getfaclo nome é bob em vez de 3000.

Resumo : Portanto, as permissões de usuário atribuídas dentro ou fora do contêiner refletem nos dois ambientes. Portanto, para gerenciar as permissões de volumes, os UIDs na máquina host devem ser diferentes dos UIDs no contêiner .