Início / computer / Perguntas / 1692592
Accepted
Brett Sutton
Asked: 2021-12-12 20:45:40 +0800 CST

sudo não pode gravar no arquivo temporário

  • 772

Estou tentando entender por que sudo não tem permissão aqui

touch fred.txt
/tmp$ ls -la fred.txt
-rw-rw-r-- 1 me me 0 Dec 12 15:40 fred.txt
/tmp$ sudo -i
~# cd /tmp
/tmp# echo hi >> fred.txt
-bash: fred.txt: Permission denied
/tmp# chmod 666 fred.txt
/tmp# ls -la fred.txt
-rw-rw-rw- 1 me me 0 Dec 12 15:40 fred.txt
/tmp# echo hi >> fred.txt
-bash: fred.txt: Permission denied
id
uid=0(root) gid=0(root) groups=0(root)

Pelo que entendi, a permissão 666 deve dar ao proprietário, grupo e outras permissões para r/w para o arquivo. Surly sudo que está agindo como root como evidenciado pelo comando id tem acesso ao arquivo sob a permissão 'other'.

O que estou entendendo errado aqui?

linux sudo

1 respostas

  1. Best Answer

    Tem algo a ver com este commit no kernel do Linux. Muitas vezes /tmpé "gravável no mundo" ("mundo" aqui significa "outros") e é "pegajoso":

    $ stat /tmp/
...
Access: (1777/drwxrwxrwt)  Uid: (    0/    root)   Gid: (    0/    root)
...

    chmod(2):

    ...
S_ISVTX  (01000)  sticky bit (restricted deletion flag, as described in unlink(2))
...
S_IWOTH  (00002)  write by others
...

    Conforme mencionado na mensagem de confirmação, isso não impede exatamente você de gravar em um arquivo afetado, mas de abrir esse arquivo com O_CREAT, que é um sinalizador para open()isso normalmente definido para acionar a criação do arquivo se o destino ainda não existir. Portanto, você ainda pode gravar em um arquivo afetado com o sinalizador não definido (o que pode ser feito com dd):

    # ls -l /tmp/meh 
-rwxrwxrwx 1 tom tom 0 Dec 12 17:33 /tmp/meh
# id
uid=0(root) gid=0(root) groups=0(root)
# echo test | dd of=/tmp/meh oflag=append conv=notrunc
dd: failed to open '/tmp/meh': Permission denied
# echo test | dd of=/tmp/meh oflag=append conv=notrunc,nocreat
0+1 records in
0+1 records out
5 bytes copied, 9.4981e-05 s, 52.6 kB/s
#

    Observe que é puramente sobre se o sinalizador está definido, mas não se um arquivo precisa ser criado, pois no caso de preocupação, o arquivo sempre existe.

    Observe também que, conforme mencionado na mensagem de confirmação, o arquivo não pôde ser aberto O_CREATnão apenas porque não era de propriedade do usuário que tentou abri-lo ( root), mas também porque seu proprietário ( tom) é diferente do proprietário ( root) de o diretório ( /tmp). Se /tmp/fosse de propriedade de tomcomo /tmp/mehera, rootteria sido capaz de abri-lo com O_CREAT.

    Veja também este commit no systemd que habilita a "proteção" nas distros que o adotaram:

    # sysctl fs.protected_regular
fs.protected_regular = 1

    Observe que os sysctls relacionados também podem ser definidos 2(ou 0) .

    • 2

relate perguntas