Conceder acesso de leitura / gravação ao usuário em apenas um diretório

Estou executando um servidor e preciso conceder acesso de leitura / gravação a um diretório específico para um único usuário. Eu tentei o seguinte:

sudo adduser abcd
sudo groupadd abcdefg
chown -R .abcdefg /var/www/allowfolder
chmod -R g+rw /var/www/allowfolder
usermod -a -G comments abcd

O acima parece funcionar, no entanto, fornece ao usuário acesso somente leitura ao restante do servidor.

Como posso configurar permissões para que o usuário possa ler e gravar apenas em uma pasta específica? O usuário também deve ser capaz de executar programas como mysql.

permissions files account-restrictions

— Manishearth
fonte

A resposta curta: use um chroot.

— Chris Baixo

@ Chris Care para elaborar isso em uma resposta? Manish e eu temos lutado com isso e não conseguimos fazê-lo funcionar.

— Desfazer

Onde o mysqlprograma estaria localizado? O usuário deve poder lê-lo e todas as bibliotecas e arquivos de dados necessários.

— Gilles 'SO- stop be evil' (

@Gilles Hmm. É uma instalação padrão do mysql do apt-get, até onde eu sei (não meu sistema, é o Undo).

— Manishearth

Respostas:

ACLs negativas

Você pode impedir que um usuário acesse determinadas partes do sistema de arquivos definindo listas de controle de acesso . Por exemplo, para garantir que o usuário abcdnão possa acessar nenhum arquivo em /home:

setfacl -m user:abcd:0 /home

Essa abordagem é simples, mas lembre-se de bloquear o acesso a tudo o que você não deseja abcdacessar.

Chroot

Para obter controle positivo sobre o que abcdpode ser visto, configure um chroot , ou seja, restrinja o usuário a uma subárvore do sistema de arquivos.

Você precisa criar todos os arquivos de que o usuário precisa (por exemplo, mysqle todas as suas dependências, se desejar que o usuário possa executar mysql) sob o chroot. Digamos que o caminho para o chroot seja /home/restricted/abcd; o mysqlprograma precisa estar disponível em /home/restricted/abcd. Um link simbólico apontando para fora do chroot não é bom porque a pesquisa de link simbólico é afetada pela prisão do chroot. No Linux, você pode fazer bom uso de montagens de ligação:

mount --rbind /bin /home/restricted/abcd/bin
mount --rbind /dev /home/restricted/abcd/dev
mount --rbind /etc /home/restricted/abcd/dev
mount --rbind /lib /home/restricted/abcd/lib
mount --rbind /proc /home/restricted/abcd/proc
mount --rbind /sbin /home/restricted/abcd/sbin
mount --rbind /sys /home/restricted/abcd/sys
mount --rbind /usr /home/restricted/abcd/usr

Você também pode copiar arquivos (mas precisará cuidar para que estejam atualizados).

Para restringir o usuário ao chroot, adicione uma ChrootDirectorydiretiva a /etc/sshd_config.

Match User abcd
    ChrootDirectory /home/restricted/abcd

Você pode testá-lo com: chroot --userspec=abcd /home/restricted/abcd/ /bin/bash

Estrutura de segurança

Você também pode usar estruturas de segurança como SELinux ou AppArmor. Nos dois casos, é necessário escrever uma configuração bastante delicada, para garantir que você não esteja deixando nenhum buraco.

— Gilles 'SO- parar de ser mau'
fonte

Uma maneira muito mais fácil de conceder permissões de leitura e gravação a um diretório específico é através da criação de grupos? Por exemplo, ele poderia criar um novo grupo e usar chown para tornar o proprietário do grupo de diretórios o grupo que foi criado e adicionar o usuário ao grupo. Por fim, dê ao diretório permissões de leitura e gravação para grupos.

— Qasim

@Qasim Isso requer que todos os arquivos tenham suas permissões e propriedade definidas conforme desejado. Há muitas coisas que podem dar errado (arquivos copiados de outros lugares ou extraídos de um arquivo com suas permissões preservadas, arquivos que precisam pertencer a outro grupo, arquivos que não devem ser legíveis por grupos, usuários que cometem erros ou podem " não se preocupe em garantir que a acessibilidade do grupo permaneça como desejado ...) para que os grupos realmente não resolvam esse problema.

— Gilles 'SO- stop be evil'

Quero dizer, eu não vejo como os arquivos teriam que ter suas próprias permissões se as permissões de grupo no diretório fossem definidas de maneira que nenhum usuário pudesse "cd" no diretório ou "ls" no diretório.

— Qasim

@Qasim Todo arquivo abaixo /var/www/allowfoldere seus subdiretórios devem estar acessíveis, não apenas /var/www/allowfolderele próprio. E, inversamente, outros arquivos não devem estar acessíveis. De fato, uma solução baseada apenas em permissões de arquivo e ACL não pode atender completamente aos requisitos: pelo menos permitiria ao usuário testar se existe um determinado nome /var/www, uma vez que eles precisam ter permissão x /var/wwwpara acessar /var/www/allowfolder.

— Gilles 'SO- stop be evil'

Ah, ok, entendo, mas se excluirmos o diretório / var disso e digamos que estamos falando de um diretório normal no diretório / home / user?

— Qasim

Você deveria usar chroot. O chrootcomando altera o diretório raiz que todos os processos filho veem. Vou dar um exemplo para demonstrar como funciona.

Isso foi escrito no local; Atualmente, não estou na frente de uma máquina UNIX. Neste exemplo, há um diretório chamado dircom três arquivos: a, b, c, e ls. Os três primeiros são arquivos regulares. lsé um hardlink para o lsbinário real, para que possamos listar arquivos enquanto estiver no chroot.

Eu vou chrootem dir. (Observe que provavelmente estou esquecendo alguns diretórios no diretório raiz.)

Aqui está a configuração, no formato de saída do shell:

$ pwd
/home/alex/test
$ l
dir
$ ls dir
a b c ls
$ ./ls dir # does the same thing
a b c ls
$ ls /
bin boot dev etc home mnt media proc sbin sys usr var

Agora eu vou chrootentrar dir. O /bin/bashargumento escolhe qual processo deve ser executado com o novo diretório raiz. O padrão é /bin/sh.

$ chroot /bin/bash dir
$ # this prompt is now from a subprocess running in the new root directory
$ PATH=/ ls
a b c ls
$ pwd
/

Agora saímos do chroot:

$ exit
$ # this prompt is now from the original bash process, from before the chroot
$ pwd
/home/alex/test

Espero que isso ilustre como o chrootcomando funciona. Basicamente, o que você precisa fazer para resolver seu problema é executar um chrootcomando como esse usuário toda vez que efetuar login. Talvez colocá-lo em um script de inicialização?

Um hardlink para um arquivo continuará a funcionar dentro de um chroot, mesmo que esse arquivo não possa ser acessado por outros meios (isso funciona porque os hardlinks apontam para inodes, não para caminhos). Portanto, para permitir ao usuário acessar, por exemplo, o mysqlcomando, você deve executar:

ln /usr/bin/mysql /path/to/chroot/target

— strugee
fonte

Mas isso não exigiria que eu configurasse um ambiente chroot inteiro com todos os links simbólicos? Não seria mais fácil executar um comando para que o novo usuário não tenha acesso aos outros diretórios, mas programas como o apache não perdem o acesso a eles?

— Manishearth

Basicamente, existe alguma maneira (via chmod) de fazer com que um usuário perca o acesso de leitura ao restante dos fs sem afetar o acesso de outros usuários?

— Manishearth

@ Manishearth não existe uma maneira simples chmod. quando você diz "não seria mais fácil executar um comando ... não perca o acesso a eles", esse comando é chroot. se você explicar o que quer dizer com "um ambiente chroot inteiro" ou por que isso seria um problema, talvez eu entenda melhor. (note que você pode dar acesso a todos os arquivos executáveis com um oneliner: ln /bin/* /path/to/chroot/target)

— strugee

@Manishearth, se meu exemplo não fizesse sentido, eu o incentivaria a brincar com chrootvocê mesmo ou me informaria o que não fazia sentido. melhor ainda, faça as duas coisas. (e ler as páginas de manual.)

— strugee

@ Manishearth Se esta resposta o ajudou suficientemente para levá-lo à resposta, considere aceitá-la.

— strugee