Início / unix / Perguntas / 499958
Accepted
Reinstate Monica
Asked: 2019-02-12 06:55:42 +0800 CST

Por que a verificação estrita de nome de arquivo do scp rejeita o último componente citado, mas não outros?

  • 772

Quando tento scp um arquivo com uma barra em seu caminho, o caminho é citado para o host local e o último componente do caminho é citado adicionalmente para o host remoto, como scp host:"a/b/'c'" ., ele falha com

protocol error: filename does not match request

a menos que eu use a -Topção. No entanto, se qualquer outro componente de caminho for citado, como scp host:"a/'b'/c" ., ele funcionará. Além disso, se o caminho não for citado para o host local, como scp host:a/b/'c' ., ele funcionará.

A página man documenta -Tcomo:

Desative a verificação estrita de nome de arquivo. Por padrão, ao copiar arquivos de um host remoto para um diretório local, o scp verifica se os nomes dos arquivos recebidos correspondem aos solicitados na linha de comando para evitar que a extremidade remota envie arquivos inesperados ou indesejados. Devido às diferenças em como vários sistemas operacionais e shells interpretam caracteres curinga de nome de arquivo, essas verificações podem fazer com que os arquivos desejados sejam rejeitados. Essa opção desativa essas verificações às custas de confiar totalmente que o servidor não enviará nomes de arquivos inesperados.

Não entendo como essa descrição explica o comportamento que vejo. Qual é a razão para o comportamento do scp? E existe alguma maneira de desativar esse "recurso"?

Estou executando o Ubuntu 16.04 e o host remoto está executando o Ubuntu 12.04.

filenames quoting

1 respostas

  1. Best Answer

    O pessoal do Ubuntu é conhecido por passar por patches imprudentes/parciais ( exemplo recente ); no seu caso, trata-se deste patch , que tem menos de 3 semanas, incluindo o tempo gasto em snapshots:

    check in scp client that filenames sent during remote->local directory
copies satisfy the wildcard specified by the user.

This checking provides some protection against a malicious server
sending unexpected filenames, but it comes at a risk of rejecting wanted
files due to differences between client and server wildcard expansion rules.

For this reason, this also adds a new -T flag to disable the check.

reported by Harry Sintonen
fix approach suggested by markus@;
has been in snaps for ~1wk courtesy deraadt@

OpenBSD-Commit-ID: 00f44b50d2be8e321973f3c6d014260f8f7a8eda

    Isso não está pronto para o horário nobre (está usando ingenuamente fnmatch(3)no nome base do arquivo) e já teve que ser corrigido para permitir expansões de chaves .

    Conclusão: é um bug; provavelmente será consertado mais cedo ou mais tarde; ou se não, esteja preparado para sempre desabilitar esse novo recurso com -T.

    • 3

relate perguntas