Por que a edição do core_pattern é restrita?

Question

Esta questão está associada a Onde está o arquivo principal com abrt-hook-cpp instalado? .

Enquanto eu estava tentando gerar um arquivo principal para um programa que falhava intencionalmente, na primeira geração de arquivos principais parecia ser frustrado pelo abrt-ccpp. Então eu tentei editar manualmente o /proc/sys/kernel/core_pattern com o vim:

> sudo vim /proc/sys/kernel/core_pattern

Quando tentei salvar o arquivo, o vim relatou esse erro:

"/proc/sys/kernel/core_pattern" E667: Fsync failed

Eu achei que isso era um problema de permissão, então tentei alterar as permissões:

> sudo chmod 666 /proc/sys/kernel/core_pattern
chmod: changing permissions of '/proc/sys/kernel/core_pattern\': Operation not permitted

Por fim, com base em este post Eu tentei isso:

>sudo bash -c 'echo /home/user/foo/core.%e.%p > /proc/sys/kernel/core_pattern'

Isso funcionou.

Com base na solução de trabalho, também tentei estas, que falharam:

> echo "/home/user/foo/core.%e.%p" > /proc/sys/kernel/core_pattern
-bash: /proc/sys/kernel/core_pattern: Permission denied
>
> sudo echo "/home/user/foo/core.%e.%p" > /proc/sys/kernel/core_pattern
-bash: /proc/sys/kernel/core_pattern: Permission denied

Pergunta :

Por que a edição, chmod ing e o redirecionamento de echo output para o arquivo /proc/sys/kernel/core_pattern all falhou, e somente a invocação observada de sudo bash... foi capaz de sobrescrever / editar o arquivo?

Pergunta :

Especificamente, execute as tentativas de invocar sudo nas tentativas com falha acima: por que elas falharam? Eu pensei que sudo executou o comando subseqüente com privilégios de root, o que eu pensei em deixar você fazer qualquer coisa no Linux.

    

Answer 1

As entradas no procfs são gerenciadas por um código ad hoc. O código que definiria permissões e propriedade dos arquivos em /proc/sys ( proc_sys_setattr ) rejeita mudanças de permissões e propriedade com EPERM. Portanto, não é possível alterar as permissões ou a propriedade desses arquivos, ponto final. Tais mudanças não são implementadas, portanto, ser root não ajuda.

Quando você tenta escrever como usuário não raiz, você recebe um erro de permissão. Mesmo com sudo echo "/home/user/foo/core.%e.%p" > /proc/sys/kernel/core_pattern , você está tentando escrever como um usuário não raiz: sudo runs echo como root, mas o redirecionamento acontece no shell do qual sudo é executado, e esse shell não tem nenhum nível elevado privilégios. Com sudo bash -c '… >…' , o redirecionamento é executado na instância bash que é lançada por sudo e que é executada como raiz, portanto, a gravação é bem-sucedida.

O motivo pelo qual somente root deve ter permissão para definir o kernel.core_pattern sysctl é que ele permite que um comando seja especificado e, como essa é uma configuração global, esse comando pode ser executado por qualquer usuário. Este é, na verdade, o caso de todas as configurações de sysctl em vários graus: elas são todas configurações globais, portanto, somente o root pode alterá-las. kernel.core_pattern é apenas um caso particularmente perigoso.

    

Answer 2

No Ubuntu 16.04 LTS,

 sudo bash -c 'echo /home/user/foo/core.%e.%p > /proc/sys/kernel/core_pattern'

falha com

No such file or directory

Eu tenho que correr

sudo sysctl -w kernel.core_pattern=/home/user/foo/core.%e.%p