sshfs permissão negada mesmo para usuário root

Question

Eu uso sshfs para montar uma pasta remota de outro servidor para o servidor local. Montar a pasta remota funciona sem problemas usando o seguinte comando:

sshfs -o allow_other someServerFromSSHConfig:/home/data/somefolder/ /some/local/folder

O problema é que não consigo alterar o dono dos arquivos usando o chown (independentemente das permissões de root). Sempre consigo:

chown: changing ownership of ‘/somefolder/file.img’: Permission denied

O usuário que acessa a pasta é membro do grupo de fusíveis. Mesmo se eu adicionar opções de montagem adicionais em sshfs para definir o proprietário como userx:groupx , não será possível alterar as permissões usando userx e usando chown -R userx:groupx [...]

Espero poder definir permissões de usuário para arquivos em pastas montadas, mas esse não é o caso.

    

Answer 1

Como você disse nos comentários, conecte-se como data @ remote_server Isso significa que você não pode chown . O sshfs é apenas uma abstração grosseira, você só tem permissão para as ações que você poderia executar dentro de sftp data@remote_server Toda abstração está vazando, essa também.

Somente root @ remote_server pode chown no remote_server. Não importa qual usuário você está no servidor local.

Observe que, para sftp root@remote_server , você geralmente precisa de PermitRoot yes ou PermitRoot without-password no /etc/ssh/sshd_config do controle remoto. Isso é arriscado.

PS. Por padrão, o sshd não permite logins root, por causa da opção PermitRoot no . Então, normalmente você não pode usar root @ host_de_sshfs. Se você quiser testar o comportamento do chown via root, eu recomendaria definir PermitRoot without-password . Isso significa que o root pode efetuar login quando uma chave pública é adicionada a /root/.ssh/authorized_keys . Com essa configuração, o root não pode efetuar login apenas fornecendo uma senha de root, portanto, é um pouco seguro.

PS2. Se você precisar de um pouco mais de segurança, você pode configurar outra instância do sshd apenas para este compartilhamento de arquivos; com ForceCommand internal-sftp e com chroot , aumentaria muito a segurança da raiz, mas precisaria usar uma nova porta TCP e uma nova exceção de firewall.

    

Answer 2

Se você quiser definir a propriedade específica do arquivo para a pasta montada sshfs, você precisa fazer isso usando uid=USER_ID_N,gid=USER_GID_N e idmap=user opções.

• uid, gid - define a propriedade relatada de arquivos para determinados valores; uid é o ID do usuário numérico do seu usuário, gid é o ID do grupo numérico do seu usuário.
• idmap - use a opção idmap com o valor do usuário para traduzir o UID do usuário de conexão. # sshfs -o idmap=user sessy@mycomputer:/home/sessy /mnt/sessy -C -p 9876 irá mapear o UID do usuário remoto "sessy" para o usuário local, que executa esse processo ("root" no exemplo acima) e o GID permanece inalterado.

One thing to be aware of is that your UID (User ID, the unique number of your user on a system) is not necessarily the same on the two hosts. When you ls -l, the user name associated with each file is printed in the third column. However, in the filesystem, only UIDs are stored, and ls simply looks up the UID and finds the user name associated with it. In Unix, UIDs are what matter, not the user names. So if you're 1000 on the local host and 1003 on the remote host, the sshfs mounted directory would show a different user name for your files. This is not a problem, though, because the ssh server on the remote machine is what is actually reading and writing files. So even though it shows up in ls -l as a different UID, any changes will be done through the ssh server on the remote host, which will use the correct UID for the remote machine. Problems may arise if you attempt to use a program that looks at UIDs of files (e.g. ls prints the wrong user name).

The idmap=user option ensures that files owned by the remote user are owned by the local user. If you don't use idmap=user, files in the mounted directory might appear to be owned by someone else, because your computer and the remote computer have different ideas about the numeric user ID associated with each user name. idmap=user will not translate UIDs for other users.

Citado em: link