Como passar um arquivo de um usuário para outro (sem criar cópias dele)?

2

Suponha que o usuário "qqq" possua o arquivo /home/qqq/bigfile.dat e queira passá-lo ao usuário "aaa" sem a ajuda do root (ele precisa ser de propriedade de "aaa"). O que os usuários "qqq" e "aaa" devem fazer?

Caminho ingênuo:

  1. uid=qqq$ mv bigfile.dat /home/aaa/
  2. uid=aaa$ chown aaa /home/aaa/bigfile.dat # Operation not permitted

Claro que isso pode ser feito usando ACLs ( uid=qqq$ setfacl u:aaa:rw- /home/aaa/bigfile.dat ) ou fazendo cópia temporária ( uid=aaa$ mv bigfile.dat bigfile.dat_ && cat bigfile.dat_ > bigfile.dat && rm bigfile.dat_ ), mas as duas formas parecem ter desvantagens.

Ambos os usuários concordam (podem emitir algum comando) para "passar" o arquivo. Deve ser rápido, preservando inode e outros atributos etc.

Como fazer isso de forma limpa?

    
por Vi. 06.09.2010 / 04:30

5 respostas

1

Sistemas unix antigos permitiam que qualquer usuário colocasse seus próprios arquivos em qualquer destino. A maioria não faz mais, porque isso criou alguns problemas de segurança:

  • Se houver cotas de uso de disco no lugar, o usuário A poderia armazenar arquivos sob despesa do usuário, colocando-os em um diretório privado. O usuário B nunca saberia, exceto comparando o uso de disco visível com suas cotas e não teria como encontrar o ladrão de cotas.

  • Alguns programas privilegiados (definir executáveis ou daemons) supõem que, se um arquivo pertencer a um usuário, esse usuário aprovou o conteúdo. Se o usuário A pudesse enviar um arquivo para o usuário B, A poderia induzir o programa privilegiado a aceitar quaisquer dados. (Este é um projeto inseguro de qualquer maneira, porque mesmo que A tenha realmente escrito o arquivo, A pode não tê-lo aprovado para essa finalidade específica; mas tais programas existem, e proibir chowns reduz os riscos.)

  • Um chown de um usuário não-root não pode ser desfeito. Mente, é um risco que você pode viver (e de fato há outras coisas que você pode fazer em um sistema de arquivos unix que só pode ser desfeito se algum outro usuário cooperar).

Até onde eu sei, é impossível mudar a propriedade de um arquivo na maioria dos sistemas unix modernos sem a cooperação do root. Raiz poderia executar o chown ou dar a A ou B a permissão para fazê-lo via sudo, mas isso requer uma intervenção de raiz mais direcionada do que normalmente é desejável.

Se as ACLs estiverem ativadas, como você observou, isso dá a maior parte dos efeitos práticos do chowning.

Se o fluxo de trabalho realmente exigir que A seja o proprietário em algum momento e B seja o proprietário em algum outro ponto, há outras opções que você pode explorar.

  • B pode usar o fakeroot para executar um programa e fazê-lo acreditar que ele está sendo executado como root, o que permite uma chown simulado que existe apenas na memória do fakeroot ( fakeroot sh -c 'chown B file; su B -c program' ).

  • Você pode jogar truques com o FUSE. Por exemplo, bindfs permite criar uma visão de uma árvore de diretórios onde os arquivos têm um proprietário diferente ( mkdir view_for_B; bindfs -u B actual_directory view_for_B ).

por 06.09.2010 / 20:41
0

Você pode mover o arquivo para algum espaço compartilhado ao qual ambos os usuários têm acesso de gravação (ou esse tipo de coisa não existe no Linux?), e então fazer o proprietário chmodá-lo para o receptor?

Minha mentalidade está enraizada no Mac OS X, o que pode ou não funcionar para você.

    
por 06.09.2010 / 15:36
0

Depende do que você quer dizer com "sem ajuda da raiz". Se você pode obter root para adicionar aaa e qqq para algum novo grupo (qualquer nome servirá) e certifique-se que o arquivo tem pelo menos r - perms para o novo grupo ... (ele pode reter rwx para o usuário aaa - então você get = > aaa: newgroup rw-r -----) então sem ajuda adicional do root aaa pode modificar e o qqq pode ler o mesmo arquivo.

Se você quiser fazer isso "contra os desejos do root", então eu consideraria um bug se você encontrasse alguma maneira que funcionasse. Muitos pensaram em evitar isso porque é um problema de segurança se aaa pode colocar um trojan em um diretório que o qqq tenha acesso e possa "acidentalmente" rodar.

    
por 06.09.2010 / 21:17
0

Ok, é muito atrevido, mas você poderia fazer:

aaa$ nc -l -p 12000 > bigfile.dat
qqq$ nc 127.0.0.1 12000 < bigfile.dat

Ou

aaa$ mkfifo /tmp/gimme
aaa$ chmod a+w /tmp/gimme
aaa$ cat /tmp/gimme > bigfile.dat
qqq$ cat bigfile.dat > /tmp/gimme

Se você quiser fazer isso sem precisar de espaço suficiente para 2 cópias de bigfile.dat, você pode usar o split e escrever um loop para enviar 1 chuck de cada vez e depois rm-lo imediatamente.

A questão principal é claro que alguém poderia fazer um nc ou um eco e corromper seu arquivo.

    
por 12.10.2010 / 06:09
-1

Uma maneira de fazer isso seria criar uma chave ssh que permita que o usuário qqq se conecte como aaa . Como qqq faça

ssh-keygen -t rsa

e decida se você quer usar uma senha ou não.

Em seguida, adicione a chave recém-criada a aaa executando isso como qqq :

ssh-copy-id -i ~/.ssh/id_rsa.pub aaa@localhost

Depois disso, você pode mover arquivos assim:

scp bigfile.dat aaa@localhost:

(ou com seu cliente sftp favorito)

Dessa forma, o sshd cuidaria de mudar a propriedade.

Usar scp / sftp para transferência local pode parecer estranho, mas pelo menos isso funciona! :)

    
por 06.09.2010 / 08:37