Acesso de gravação sem acesso de leitura

É possível que um usuário tenha acesso de gravação a um arquivo e não consiga lê-lo? Como isso é possível?

Eu tentei os seguintes comandos:

debianbox@debian:~/posix/io$ touch filetest
debianbox@debian:~/posix/io$ ls -l filetest
-rw-r--r-- 1 debianbox debianbox 0 14 oct.  03:10 filetest

debianbox@debian:~/posix/io$ echo "Hello World" > filetest
debianbox@debian:~/posix/io$ cat filetest
Hello World

debianbox@debian:~/posix/io$ chmod u-r filetest
debianbox@debian:~/posix/io$ cat filetest
cat: filetest: Permission forbidden

debianbox@debian:~/posix/io$

Como você pode ver aqui, tenho acesso de gravação, mas não de leitura, neste arquivo. Como isso pode ser possível? Isso é considerado um bug? Caso contrário, em que situação isso seria útil?

Não é um bug, é um recurso ^TM (Além disso, apenas uma consequência da abordagem unix universal de permissões).

Além do comportamento do tipo dropbox no caso de diretórios (conforme descrito pelo BillThor), o acesso somente para gravação é necessário para alguns arquivos (pseudo-) especiais sob /proce /sys. Esses arquivos são usados ​​para definir algumas propriedades do driver ou do kernel ou acionar uma ação do sistema. Você não pode lê-los, porque eles são usados ​​apenas para sinalização unidirecional - você só pode reproduzir alguns textos / dados. Para encontrar esses arquivos, você pode usar

find /proc/[^0-9]* /sys -perm /222 ! -perm /444

Observe que, como esses arquivos são usados ​​para configuração avançada do sistema (potencialmente perigosa), somente roothá acesso de gravação a eles (na maioria dos casos).

O principal motivo para permitir o acesso de gravação sem acesso de leitura é que simplifica o gerenciamento de permissões, tanto dentro do kernel quanto nos programas do usuário. Existem duas permissões, uma para leitura e outra para gravação, e elas são gerenciadas independentemente. Isso não é um bug, pois o comportamento documentado coincide com o comportamento real e não há boas razões para exigir um comportamento diferente.

Ter permissões de gravação sem permissões de leitura não faz muito sentido para arquivos regulares. Faz sentido para vários arquivos especiais.

• Alguns sistemas permitem arquivos somente anexados. Isso é útil para arquivos de log, por exemplo. Pode fazer sentido permitir que muitos usuários criem entradas de log, mas não apagar ou substituir entradas existentes (por exemplo: permissão de gravação, mas atributo somente de acréscimo), nem permitir a leitura de entradas de outras pessoas (portanto: não permissão de leitura).
• Um programa pode ter permissão para gravar em um pipe nomeado sem ter permissão para ler dele.
• Alguns dispositivos são somente gravação. Por exemplo, um dispositivo de saída de som conectado a um alto-falante, mas nenhum microfone deve ter permissão de gravação, mas não de leitura.
• Existem vários sistemas de arquivos especiais nos quais a leitura ou gravação em um arquivo tem um efeito imediato, em vez de recuperar ou adicionar dados ao armazenamento. Por exemplo, no Linux, existem vários arquivos /proce /syspermitem que os programas de espaço do usuário enviem comandos ao kernel gravando em um arquivo específico. Se esse comando não fornecer nenhum feedback, o arquivo especial será criado somente para gravação.

Não, isso não é um bug. No entanto, não o vejo comumente aplicado a arquivos.

Na maioria das vezes, vi acesso apenas de gravação nos diretórios do dropbox. Os usuários podem adicionar arquivos ao diretório, mas não podem ver quais arquivos existem.

Para um arquivo de texto comum, somente o acesso de gravação seria apropriado para o acesso do tipo dropbox.

Definir o acesso somente de gravação para si mesmo não seria muito útil, mas não permitir isso complicaria o código de permissões.

EDIT: É provável que os arquivos do Dropbox não sejam úteis. No entanto, pode ser útil para logs não raiz, pois dificulta a substituição de entradas de log. Se você pode ler o arquivo, é muito mais fácil identificar onde gravar uma entrada de log de substituição. No entanto, não conheço ninguém que configure seus logs dessa maneira. É comum usar o log remoto para impedir a modificação local das entradas do log.

Definir regras nas quais combinações de permissões são permitidas pode levar à prevenção de permissões úteis imprevistas. Muitas combinações fazem mais sentido no nível do grupo ou do mundo do que no nível do proprietário. Qualquer tentativa de impedir o acesso pelo proprietário pode ser facilmente substituída. No entanto, eles podem ser úteis para forçar um segundo sóbrio.