Permissões incorretas em arquivos especiais

Question

Eu notei que muitos arquivos especiais no Linux têm o que parecem ser permissões incorretas:

Por exemplo:

$ ls -l /dev/fuse 
  crw-rw-rw- 1 root root 10, 229 May 29 09:59 /dev/fuse

aparece gravável, mas na verdade não é

$ echo 1 > /dev/fuse
  -bash: echo: write error: Operation not permitted

Mesmo por exemplo, para todos os arquivos em /proc/$pid/attr :

$ ls -l /proc/1/attr/
total 0
-rw-rw-rw- 1 root root 0 May 30 11:01 current
-rw-rw-rw- 1 root root 0 May 30 11:01 exec
-rw-rw-rw- 1 root root 0 May 30 13:31 fscreate
-rw-rw-rw- 1 root root 0 May 30 11:01 keycreate
-r--r--r-- 1 root root 0 May 30 11:01 prev
-rw-rw-rw- 1 root root 0 May 30 11:01 sockcreate
$ echo 1 >| /proc/1/attr/keycreate 
-bash: echo: write error: Permission denied

Isso é um bug?
(BTW, não tenho idéia do que esses arquivos fazem).

    

Answer 1

Acho que meus dois comentários podem ser uma resposta ...

1) nunca "> arquivo" se você não sabe para que arquivo é (ou como ele é usado) ... você pode limpá-lo / estragar tudo além do reparo ...

2) para seus dois exemplos particulares:

• / dev / fuse é usado para: en.wikipedia.org/wiki/Filesystem_in_Userspace. Por exemplo, se você usar "sshfs", ou algo assim. Quando não estiver em uso, ele não levará a nada (as permissões estão corretas, mas atualmente não estão apontando / levando a nada). Quando em uso, pode levar a um sistema de arquivos viável, que você pode atrapalhar ou até mesmo destruir se você ">" para isso ... [ymmv]

• E / proc / 1 é para "init", com o qual você não quer mexer.

(E há muitos outros com quem você não quer mexer ... ^^)

    

Answer 2

Estes não são simplesmente arquivos como no ext4 e outros sistemas de arquivos familiares ...

# mount | grep -E "on /proc |on /dev "
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,...)

No caso de / proc, você tem um sistema de arquivos virtual, procfs, que representa coisas acontecendo no kernel, e essas coisas não são realmente arquivos, mas uma interface baseada em arquivos no kernel. Eles são apoiados por algum driver que tem um trabalho diferente de apenas organizar bytes de dados e metadados. Em tais "sistemas de arquivos virtuais", pode haver um comportamento especial que parece desafiar sua compreensão normal dos sistemas de arquivos.

Por exemplo, isso pode parecer estranho:

# echo hi > /proc/testfile
-bash: /proc/testfile: No such file or directory

No caso de / dev, que é um tmpfs, devtmpfs (no Arch sem systemd por exemplo), ou devfs (FreeBSD por exemplo), e talvez algo mais com o systemd, as coisas se comportam como em um sistema de arquivos normal (ou potencialmente não), mas geralmente tem "arquivos especiais" em vez de arquivos regulares. Você pode copiá-los para outro sistema de arquivos ou fazer o seu próprio (por exemplo, com mknod ou mkfifo) para ver como eles se comportam de maneira diferente. Com um arquivo especial "echo hi > somefile" pode não significar "abrir o arquivo, truncá-lo e escrever oi", mas encaminhar o "oi" para algum driver ou outra coisa.

# file /dev/sda /dev/mem /dev/fuse /dev/null
/dev/sda:  block special (8/0)
/dev/mem:  character special (1/1)
/dev/fuse: character special (10/229)
/dev/null: character special (1/3)

# file -s /dev/sda /dev/mem /dev/fuse /dev/null
/dev/sda:  DOS/MBR boot sector, extended partition table (last)
/dev/mem:  ERROR: cannot read '/dev/mem' (Operation not permitted)
/dev/fuse: ERROR: cannot read '/dev/fuse' (Operation not permitted)
/dev/null: empty

Mas copiá-los com o cp não funciona (sempre?). (Eu esqueço como fazer isso, ou possivelmente imaginei)

# cp /dev/null /tmp
# file -s /tmp/null
/tmp/null: empty
# echo hi > /tmp/null
# file -s /tmp/null
/tmp/null: ASCII text

# cp /dev/sda /tmp/
... it is copying the whole disk to /tmp now ... hit ctrl+c