Eu passei um tempo considerável procurando por uma resposta mais completa para essa pergunta. Configurar uma umask diferente para o sftp é bom, mas não é uma resposta universal, já que o umask irá restringir somente permissões e não conceder permissões adicionais. As permissões exatas de um arquivo enviado via sftp dependem também das permissões do arquivo original e do cliente usado para o upload.
Como exemplo, configurei o umask no meu servidor sftp (OpenSSH, em um servidor Red Hat) para 0002, mas se eu fizer upload de um arquivo de texto com as 0600 permissões no sistema de origem usando o cliente sftp do OpenSSH, ainda terá 0600 permissões no destino. Notavelmente, isso significa que não posso, tanto quanto seja do meu conhecimento, garantir que os arquivos enviados a este servidor sftp tenham permissões de grupo, o que, por extensão, também não pode usar listas de controle de acesso (ACL) para estender permissões a outros usuários ou grupos. .
Para tentar dois métodos que resolveriam isso, embora em ambos os casos eles sejam mais soluções do que soluções:
- Crie um cron job para definir manualmente as permissões desejadas após o fato. Simples o suficiente, mas assíncrono, mesmo que você possa executá-lo com freqüência.
- Use inotify para monitorar os diretórios de destino usados pelo servidor sftp e defina as permissões desejadas para quaisquer arquivos criados em eles. Isso deve ser praticamente imediato, mas pode ter outras limitações, como no caso de um grande número de arquivos ou diretórios.
Eu encontrei um post no blog do site positon.org que explica bem a opção inotify, com exemplos e até mesmo scripts init. É melhor ler lá, mas no caso do site desaparecer, o comando é:
inotifywait -mrq -e CREATE --format %w%f /tmp/mytest/ | while IFS= read -r FILE; do chmod g=u "$FILE"; done
Por mais simples que seja, eu ainda estaria muito interessado em uma maneira, por recurso ou truque, de obter o mesmo resultado dentro do sftp ou pelo menos do shell, sem envolver utilitários separados.