Por que os clientes SFTP não podem renomear um arquivo no diretório inicial montado pelo NFS?

Question

Eu tenho uma instância do Amazon Linux executando o SSH agindo como um servidor SFTP. Os clientes efetuam login e são chrootados em um diretório montado pelo NFS. Os usuários podem ler, gravar e excluir arquivos, mas a renomeação de arquivos falha com um "erro de protocolo" não específico.

Aqui está uma cópia do meu arquivo sshd_config :

Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
UsePrivilegeSeparation yes

KeyRegenerationInterval 3600
ServerKeyBits 1024

SyslogFacility AUTH
LogLevel INFO

LoginGraceTime 120
PermitRootLogin prohibit-password
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes

IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no

PermitEmptyPasswords no

ChallengeResponseAuthentication no

PasswordAuthentication yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

AcceptEnv LANG LC_*

# Subsystem sftp /usr/lib/openssh/sftp-server -u 0002
Subsystem sftp internal-sftp -l DEBUG -u 002 -d %u

UsePAM yes
Match Group sftpusers
    ChrootDirectory /autohome
    AllowTCPForwarding no
    X11Forwarding no
    ForceCommand internal-sftp -l DEBUG -u 002 -d %u

Eu vi a referência à renomeação do sftp não funcionar quando a origem e o destino estão em sistemas de arquivos separados, mas esse não é o caso aqui. Eu também vi a referência a renomear sftp não funcionar em sistemas de arquivos que não suportam hard links, mas acho que nosso servidor NFS (AWS File Storage Gateway) deve estar bem. Eu estou em uma perda, qualquer ajuda é apreciada.

    

Answer 1

Graças à dica do @ Kenster, encontrei o problema. Eu estava enganado ao supor que a montagem NFS do AWS File Storage Gateway suportava links físicos, como a documentação afirma claramente que isso não acontece.

Eu estava tão certo de que era o caso que acabei rastreando as chamadas do sistema com strace. Se você anexar um cliente sftp ao seu servidor enquanto estiver ssh, adicione o pid do processo sftp atual com ps -eaf | grep sftp . Então você pode rastrear as chamadas do sistema com strace e salvar a saída em um arquivo com este comando: strace -ff -p 2116 -o sftp_rename.log onde -ff está seguindo os processos filhos, -p é o pid e -o é o arquivo de saída.

Isso vai te dar uma saída realmente terrível, mas o que achei interessante foi esse:

write(7, "
# ln asdfasdf.txt link.txt
ln: failed to create hard link ‘link.txt’ => ‘asdfasdf.txt’: Unknown error 524
#
    oldpath = self._adjust_cwd(oldpath)
    newpath = self._adjust_cwd(newpath)
    self._log(DEBUG, 'posix_rename({!r}, {!r})'.format(oldpath, newpath))
    self._request(
        CMD_EXTENDED, "[email protected]", oldpath, newpath
    )
write(7, "
# ln asdfasdf.txt link.txt
ln: failed to create hard link ‘link.txt’ => ‘asdfasdf.txt’: Unknown error 524
#
    oldpath = self._adjust_cwd(oldpath)
    newpath = self._adjust_cwd(newpath)
    self._log(DEBUG, 'posix_rename({!r}, {!r})'.format(oldpath, newpath))
    self._request(
        CMD_EXTENDED, "[email protected]", oldpath, newpath
    )
%pre%L%pre%%pre%%pre%%pre%%pre%%pre%Drename old \"/testuse"..., 80) = 80
lstat("/testuser/test/asdfasdf.txt", {st_mode=S_IFREG|0664, st_size=159, ...}) = 0
link("/testuser/test/asdfasdf.txt", "/testuser/test/as.txt") = -1 ENOTSUPP (Unknown error 524)
L%pre%%pre%%pre%%pre%%pre%%pre%Drename old \"/testuse"..., 80) = 80
lstat("/testuser/test/asdfasdf.txt", {st_mode=S_IFREG|0664, st_size=159, ...}) = 0
link("/testuser/test/asdfasdf.txt", "/testuser/test/as.txt") = -1 ENOTSUPP (Unknown error 524)

Que eu então testei com um simples comando de link para criar um link físico, que falhou.

%pre%

O que me levou de volta à documentação da AWS. Isso não é tudo, aparentemente, renomear SFTP vai trabalhar com determinados clientes (como a Paramiko) que implementam um protocolo CMD_EXTENDED específico do vendedor, como A Paramiko faz :

%pre%

Parece não haver nenhuma maneira de forçar o uso da opção posix-rename para todos os clientes, mas pelo menos sabemos o que aconteceu e por quê.