Desafio do diretório de grupos

2

Tenha uma pergunta desafiadora para você. Tem uma caixa linux. Precisa criar um diretório em que os usuários possam criar arquivos, mas remova / modifique apenas os arquivos criados por eles. Simples o suficiente para ter um bit sticky definido e pronto. Mas queremos que um usuário administrador particular possa remover arquivos desse diretório e não ser usuário root. Como fazer isso? NFS4_ACLs são possíveis lá. Mas tenho certeza que eles não vão ajudar. Idéias? Comercial: user1: uploaders user2: uploaders admin1: admins < --- devem conseguir gerenciar arquivos no diretório do grupo

O

sgid on dir torna possível proteger os arquivos de serem editados por outros usuários, mas nada impede que o usuário exclua os arquivos de outros usuários. Esse é o problema

UPDATE 1:

A questão era para permissões FS e nfs4_acls apenas porque os usuários estariam trabalhando com arquivos através de sftp. Assim, o sudo e outras formas de script não são possíveis. Possível é usar o LD_PRELOAD para o sftp-server e sobrepor o syscall do unlink ou algo parecido. Então ele entra no openssh e no sftp-server.

UPDATE 2:

Os usuários são chrooted para o diretório em questão pelo openssh e o diretório deve ser root: root de propriedade para ele funcionar. Todos os arquivos são colocados neste diretório sem nenhuma estrutura (aplicativo específico). O administrador não é, na verdade, o único usuário a gerenciar os arquivos enviados, mas sim um grupo de usuários administradores.

    
por Dmytro Leonenko 28.03.2015 / 20:38

6 respostas

1

Eu estaria inclinado a resolver com sudo em vez de ACLs. (Não há menção explícita do NFS na questão, então vou assumir que root_squash não é um problema.)

Comece com o seu diretório com as permissões 1777 (fixas, mais todas as leituras / gravações) como você sugeriu.

Crie este script com um nome de arquivo, como /usr/local/bin/rmd . Altere a definição de TARGET para que seja o caminho absoluto para o diretório de destino

#!/bin/bash
#
# Remove files from $TARGET. Some care is taken to avoid escaping from
# the path root
#
########################################################################
#
TARGET='/tmp'

ERROR=
for ITEM in "$@"
do
    LINK=$(readlink -f "$ITEM")
    if test -n "$LINK" && echo "$LINK" | grep -vq "^$TARGET/"
    then
        echo "Suspicious path: $ITEM" >&2
        ERROR=yes
    fi
done
test yes = "$ERROR" && exit 1

exec rm "$@"

Adicione a seguinte entrada ao arquivo sudoers (use visudo para editar este arquivo). Altere o admin para ser o usuário com privilégios administrativos para excluir arquivos no diretório de destino.

admin ALL = NOPASSWD: /usr/local/bin/rmd

Como sabemos que rmd está em /usr/local/bin , seria possível refazer% deexec do script se ele não tivesse privilégios suficientes e, portanto, evitar que o usuário administrativo tenha que se lembrar de usar sudo , mas eu omiti isso por enquanto. Deixe-me saber se você deseja esse ajuste no script.

Exemplo de uso

$ ls -l /tmp
lrwxrwxrwx 1 roaima roaima 4 Mar 31 00:17 etc -> /etc
-rw-r--r-- 1 roaima roaima 0 Mar 31 00:29 one
lrwxrwxrwx 1 roaima roaima 2 Mar 31 00:20 root -> ..
-rw-r--r-- 1 roaima roaima 0 Mar 31 00:29 two

$ sudo rmd /tmp/etc/hosts /tmp/root/etc/motd /tmp/one
Suspicious path: /tmp/etc/hosts
Suspicious path: /tmp/root/etc/motd

$ ls /tmp
etc  one  root  two

$ sudo rmd /tmp/one /tmp/root
$ ls /tmp
etc  two
    
por 31.03.2015 / 01:35
0

O Bindfs é uma solução possível. Eu nomeei meu power admin user nradmin e aqui está o exemplo:

mkdir /uploads
chmod 1777 /uploads

mkdir /home/nradmin/manage-uploads
bindfs -u nradmin -p ud+rwx /uploads /home/nradmin/manage-uploads

Todos os arquivos e diretórios no destino montado são de propriedade de nradmin . O -p ud+rwx faz com que todos os diretórios estejam com permissões "rwx" para o proprietário do diretório. Como nradmin é o proprietário de todos os diretórios e possui permissões completas de proprietário, ele pode excluir com êxito qualquer arquivo, mesmo recursivamente.

A abordagem alternativa seria codificar uma implementação limitada de chroot() de /bin/rm e executá-la como root . Um chroot() pode ser ignorado por um processo executado por root , mas somente se você der a esse processo a liberdade de executar o que quiser. Um simples binário C que primeiro torna chdir() & chroot() para o diretório /uploads e, em seguida, somente as chamadas unlink() ou rmdir() devem ser seguras. Mas isso requer muita codificação como exclusão recursiva de diretórios, uma opção de linha de comando como -f para ignorar arquivos não existentes, etc.

    
por 03.04.2015 / 22:13
0

Uma solução simples parece ser esta. Considere o usuário administrativo como admin e que nosso diretório especial deve ser /tmp/special .

mkdir /tmp/special
chmod 1777 /tmp/special
chown admin:admin /tmp/special
ls -ld /tmp/special
drwxrwxrwt 2 admin admin 4096 Apr  3 21:34 /tmp/special

Qualquer usuário pode criar / editar / excluir seus próprios arquivos em /tmp/special . O usuário admin pode excluir qualquer arquivo (embora com avisos de rm ).

NB Se um usuário criar um diretório em /tmp/special , o usuário administrativo não poderá removê-lo. Isso pode ser um impedimento para essa solução, mas como sua pergunta apenas mencionou arquivos e não diretórios , senti que valeria a pena ser oferecido.

    
por 03.04.2015 / 22:40
0

O escopo completo desse problema não está claro, já que não sabemos qual é o usecase. No entanto, usando os rótulos do SELinux, obtenha o que você deseja. O SELinux oferece a você alguns controles refinados sobre quem faz o quê e onde. Se o número de usuários é "limitado" e "conhecido" - ter contextos / rótulos específicos associados a cada um deles não é um grande problema, então é uma questão de escrever um pouco de política para codificar seus requisitos.

    
por 06.04.2015 / 07:58
0

Hmm ... que tal chrooting para /special_folders_root/special_folder/./ para evitar problemas com diretórios chrooted de propriedade da raiz? Veja a documentação do vsftpd (por exemplo) para explicação sobre ponto estranho no caminho.

Não tenho certeza se seguir será útil, mas: Temos compartilhamento de samba com subdiretórios. MFUs de rede colocando os documentos digitalizados dentro de subdiretórios específicos (MFU01 - > / share / 001 /, MFU15 - > / share / 015 / etc). Os usuários (das janelas) podem alterar ou remover os arquivos em qualquer um desses subdiretórios, mas não podem remover os subdiretórios. Eu fiz isso usando ACLs no estilo windows, mas não sei nada sobre as ACLs do NFS

NB! Não por recompensa, mas por assistência.

    
por 09.04.2015 / 01:11
0

Como sobre essa abordagem:

Mantenha os arquivos originais carregados em um diretório separado, por usuário. Isso abrange as permissões de controle e exclusão.

Em $share , tudo é um link para os arquivos originais e as ACLs do proprietário / administrador estão em vigor.

No final, cada item em $share é um link de volta. Qualquer coisa que não é , um link é movido para a pasta do proprietário (uploader).

    
por 09.04.2015 / 01:44