if a core file owned by a non root user exists and root runs a process that drops core in the same location, the original core file owned by the non root user is replaced with root's core dump, except the original owner maintains ownership of the core. linux 2.4, 2.6, and obsd operate in the same manner. i have not tested other platforms i do understand that mitigating factors, such as configuring where and how cores are created, but this doesn't seem right. How-To-Repeat: trew:~/tmp/q$ ./t Segmentation fault (core dumped) trew:~/tmp/q$ md5sum core 90b29a1012aa00c34a18947d98f1b1fb core trew:~/tmp/q$ ls -l core -rw------- 1 trew users 61440 Jul 10 19:13 core trew:~/tmp/q$ su Password: root:/home/trew/tmp/q# ./t Segmentation fault (core dumped) root:/home/trew/tmp/q# md5sum core 371c0748df009ed1da6f189cceff8aca core root:/home/trew/tmp/q# ls -l core -rw------- 1 trew users 61440 Jul 10 19:13 core
Blake, I just found your PR has never been touched by anybody. I'm sorry nobody ever answered this. If the root touches any file, which already existed before, the file owner does not change. This is also the case when using `su' to get superuser rights. In your case, the file core has been created by user 'trew' and while root also writes to that file, it doesn't change file ownership. I'm seeing this as 'by design' and not a bug. Do you agree to have your PR being closed? Thanks!
State Changed From-To: open->feedback Note that submitter has been asked for feedback.
Sometimes it's good to have more than two eyes looking at something... antoine@ pointed out, that this has already been figured out to be an issue in the Linux kernel. I haven't seen that fact in the first place but have checked current kernel sources and figured out, this is really an issue. secteam@ has been contacted. Blake, thanks for bringing this to attention, even while it hasn't been noticed for a long time!
State Changed From-To: feedback->analyzed Being looked at by Volker Werth.
Here is a patch, not much tested and obtained from OpenBSD.
replying to myself, this patch is probably wrong when acls are used...
Antoine, as I noted in an internal message to secteam, I think the correct solution is to just unlink a previous existing core dump and then proceed regular.
Responsible Changed From-To: freebsd-bugs->secteam reassign to secteam.
I considered the patch attached, also I looked at the NetBSD handling of this situation. IMO the patch is fine, but also I do not see a need to avoid writing core into other-readable files. Lets do it same as NetBSD: if core file exists and its owner is not the real user of the process, do not dump.
A commit references this bug: Author: kib Date: Sun Jun 23 18:35:11 UTC 2019 New revision: 349320 URL: https://svnweb.freebsd.org/changeset/base/349320 Log: coredump: avoid writing to core files not owned by the real user. Reported by: blake frantz <trew@hick.org> PR: 68905 admbugs: 358 Sponsored by: The FreeBSD Foundation MFC after: 1 week Changes: head/sys/kern/kern_sig.c
A commit references this bug: Author: kib Date: Sun Jun 23 21:15:31 UTC 2019 New revision: 349324 URL: https://svnweb.freebsd.org/changeset/base/349324 Log: Switch to check for effective user id in r349320, and disable dumping into existing files for sugid processes. Despite using real user id pronounces the intent, it actually breaks suid coredumps, while not making any difference for non-sugid processes. The reason for the breakage is that non-existent core file is created with the effective uid (unless weird hacks like SUIDDIR are configured). Then, if user enabled kern.sugid_coredump, core dumping should not overwrite core files owned by effective uid, but we cannot pretend to use real uid for dumping. PR: 68905 admbugs: 358 Sponsored by: The FreeBSD Foundation MFC after: 1 week Changes: head/sys/kern/kern_sig.c
A commit references this bug: Author: kib Date: Wed Jul 3 19:34:18 UTC 2019 New revision: 349687 URL: https://svnweb.freebsd.org/changeset/base/349687 Log: MFC r349320, r349324: coredump: avoid writing to core files not owned by the effective user. PR: 68905 admbugs: 358 Changes: _U stable/12/ stable/12/sys/kern/kern_sig.c
A commit references this bug: Author: kib Date: Wed Jul 3 19:46:06 UTC 2019 New revision: 349689 URL: https://svnweb.freebsd.org/changeset/base/349689 Log: MFC r349320, r349324: coredump: avoid writing to core files not owned by the effective user. PR: 68905 admbugs: 358 Changes: _U stable/11/ stable/11/sys/kern/kern_sig.c
Keyword: patch or patch-ready – in lieu of summary line prefix: [patch] * bulk change for the keyword * summary lines may be edited manually (not in bulk). Keyword descriptions and search interface: <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>