Acesso de gravação sem acesso de leitura

12

É possível que um usuário tenha acesso de gravação a um arquivo e não possa 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, eu escrevi mas não li o acesso neste arquivo. Como isso pode ser possível? Isso é considerado um bug? Se não, em que situação isso seria útil?

    
por Dimitri 14.10.2011 / 03:26

3 respostas

17

Não é um bug, é um recurso TM (também, apenas uma conseqüência da abordagem unix universal às permissões).

Além do comportamento tipo dropbox no caso de diretórios (conforme descrito por BillThor), o acesso somente gravação é necessário para alguns arquivos (pseudo-) especiais em /proc e /sys . Esses arquivos são usados para definir algumas propriedades de driver ou 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 fazer eco de algum texto / dados para eles. 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 perigosos), somente root tem acesso de gravação a eles (na maioria dos casos).

    
por 14.10.2011 / 09:29
16

O principal motivo para permitir 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 escrita, e elas são gerenciadas independentemente. Isso não é um bug, pois o comportamento documentado coincide com o comportamento real e não há uma boa razão 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 permitir que eles apaguem ou substituam entradas existentes (portanto: permissão de gravação, mas atributo somente de anexação), nem permitir que leiam entradas de outras pessoas (portanto: não permissão de leitura).
  • Um programa pode ter permissão para gravar em um pipe nomeado sem permissão para ler a partir dele.
  • Alguns dispositivos são somente para 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 nenhuma permissã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, há vários arquivos em /proc e /sys que permitem que os programas de espaço do usuário enviem comandos para o kernel gravando em um arquivo específico. Se esse comando não fornecer nenhum feedback, o arquivo especial será criado somente para gravação.
por 16.10.2011 / 01:29
2

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

Eu tenho visto mais frequentemente escrever apenas o acesso em diretórios de dropbox. Os usuários podem adicionar arquivos ao diretório, mas não conseguem ver quais arquivos existem.

Para um arquivo de texto normal, o acesso somente para gravação seria apropriado para o acesso ao tipo de caixa de depósito.

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

EDIT: Arquivos do Dropbox provavelmente não serão úteis. No entanto, pode ser útil para logs não raiz, pois tornaria mais difícil substituir as entradas de log. Se você puder ler o arquivo, será muito mais fácil identificar onde gravar uma entrada de registro de substituição. No entanto, eu não conheço ninguém que define seus registros como este. É comum usar o log remoto para impedir a modificação local de entradas de log.

A definição de regras nas quais as combinações de permissão 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 o nível do proprietário. Quaisquer tentativas de impedir o acesso do proprietário podem ser facilmente substituídas. No entanto, eles podem ser úteis para forçar o segundo sóbrio embora.

    
por 14.10.2011 / 04:51