Como fazer backup dos arquivos de sombra / etc / {, g} com permissão 0000?

Question

Estou tentando fazer backup de vários servidores ' /etc usando rsync de outro servidor. Veja um snippet relevante:

PRIVKEY=/path/to/private.key
RSYNC_OPTS="--archive --inplace --no-whole-file --quiet"
ssh -n -i $PRIVKEY root@${ip} "rsync $RSYNC_OPTS /etc 192.168.25.6::"'$(hostname)'

em que ${ip} é o endereço IP do servidor a ser copiado, enquanto 192.168.25.6 é o endereço IP do servidor que armazena o backup.

Tudo correu bem, exceto pelos arquivos /etc/{,g}shadow em alguns servidores. Como suas permissões são 0000 , o rsync parece não querer lê-las (erros "Permission denied (13)").

Uma verificação rápida usando o seguinte:

ssh -i $PRIVKEY root@${ip} "cat /etc/{,g}shadow"

despejou com sucesso os arquivos.

Existe uma maneira de contornar essa limitação de rsync?

EDITs

O servidor de backup é o Ubuntu 12.04. Os servidores para backup são uma miscelânea de servidores Ubuntu, RHEL, OEL e CentOS.

Eu tentei adicionar -t às opções ssh e prefixar o rsync com sudo , mas ainda tenho os mesmos erros.

    

Answer 1

As permissões de arquivo não se aplicam ao root: os programas executados como root podem ler e gravar arquivos independentemente das configurações de proteção. (No entanto, mesmo o root não pode executar um arquivo, a menos que um dos bits de execução seja definido; não importa qual deles). Isso explica porque cat pode fazer isso. Mas, aparentemente, rsync executa sua própria verificação para conter o que pode ser copiado. Portanto, não é uma "limitação", mas um comportamento intencional (não que seja um consolo para você). Digo "aparentemente" porque não encontrei nenhuma documentação para esse comportamento.

(Desculpas se estou apenas reafirmando sua pergunta! Não tenho certeza da sua descrição.)

Se o problema estiver limitado aos arquivos de sombra, eu gostaria de adicionar a chamada a cat ao seu script de backup e ignorar o erro rsync desses arquivos. Você pode adicionar lógica para sincronizar apenas os arquivos de sombra quando eles forem alterados, mas na verdade eles são pequenos o suficiente para não incomodar.

    

Answer 2

Eu não posso dizer exatamente por que o seu rsync está falhando, porque a cópia do rsync funciona em meus sistemas.

No entanto, posso dar uma receita para determinar por que o rsync falha. Como root no servidor para backup:

cd /tmp
echo foo > tst
chmod 0000 tst
strace -fo strace-cat.out \
    cat tst
strace -fo strace-rsync.out \
    rsync -av --quiet tst tst.2
# set RSYNC_OPTS and hostname before executing following
strace -fo strace-remote-rsync.out \
    rsync $RSYNC_OPTS --quiet tst 192.168.25.6:/tmp/tst.3

Isso divide o problema em três partes - um bem-sucedido local open / read / close para cat, um rsync local (que pode ser bem sucedido) e um rsync remoto, que falhará como o seu está fazendo.

Você poderá ver a partir da saída strace em strace-remote-rsync.out (e talvez strace-rsync.out) qual chamada de sistema está falhando. E você verá que o rsync é uma operação muito mais complexa, com subprocessos e diferentes E / S. Ele usa mmap (2) para carregar o arquivo na memória, ao invés de abrir (2) para obter um descritor de arquivo para ele.