10

This question is associated with Where is core file with abrt-hook-cpp installed? .

While I was trying to generate a core file for an intentionally-crashing program, at first core file generation seemed to be stymied by abrt-ccpp. So I tried to manually editing /proc/sys/kernel/core_pattern with vim:

> sudo vim /proc/sys/kernel/core_pattern

When I tried to save the file, vim reported this error:

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

I thought this was a permission problem, so I tried to change permissions:

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

Finally, based on this post, I tried this:

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

This worked.

Based on the working solution, I also tried these, which failed:

> 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

Question:

Why is it that editing, chmoding, and redirecting echo output to the file /proc/sys/kernel/core_pattern all failed, and only the noted invocation of sudo bash... was able to overwrite/edit the file?

Question:

Specifically, wrt the attempts to invoke sudo in the failed attempts above: why did they fail? I thought sudo executed the subsequent command with root privilege, which I thought let you do anything in Linux.

Community
  • 1
StoneThrow
  • 1,575
  • 5
  • 19
  • 41

3 Answers3

13

Entries in procfs are managed by ad hoc code. The code that would set permissions and ownership on the files under /proc/sys (proc_sys_setattr) rejects changes of permissions and ownership with EPERM. So it isn't possible to change the permissions or ownership of these files, full stop. Such changes are not implemented, so being root doesn't help.

When you try to write as a non-root user, you get a permission error. Even with sudo echo "/home/user/foo/core.%e.%p" > /proc/sys/kernel/core_pattern, you're trying to write as a non-root user: sudo runs echo as root, but the redirection happens in the shell from which sudo is executed, and that shell has no elevated privileges. With sudo bash -c '… >…', the redirection is performed in the bash instance which is launched by sudo and which runs as root, so the write succeeds.

The reason only root must be allowed to set the kernel.core_pattern sysctl is that it allows a command to be specified and, since this is a global setting, this command could be executed by any user. This is in fact the case for all sysctl settings to various degrees: they're all global settings, so only root can change them. kernel.core_pattern is just a particularly dangerous case.

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
3

On Ubuntu 18.04 I can update the pattern with:

sudo bash -c 'echo "/data/app_crash/%t.%e.core.%p" > /proc/sys/kernel/core_pattern'

I can also update /etc/sysctl.conf and add the line:

kernel.core_pattern = /data/app_crash/%t.%e.core.%p

However, even though there are no other lines setting kernel.core_pattern in /etc/sysctl.conf or /etc/sysctl.d/*, after I reboot the pattern is set to the default value again:

$ sudo sysctl -a | grep kernel.core_pattern
kernel.core_pattern = |/usr/share/apport/apport %p %s %c %d %P

It turned out that apport was over-writing any changes I made. I uninstalled apport with sudo apt-get remove apport and then my changes were used.

Earl Ruby
  • 479
  • 4
  • 5
1

On Ubuntu 16.04 LTS, 

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

fails with 

No such file or directory

I have to run 

sudo sysctl -w kernel.core_pattern=/home/user/foo/core.%e.%p
Prvt_Yadav
  • 5,732
  • 7
  • 32
  • 48
Tom Phan
  • 11
  • 1