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


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?


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.


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.


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.