[PATCH] Set PR_SET_DUMPABLE before switching uid to allow core dumps.
Signed-off-by: Thomas Liske <liske@ibh.de> --- This patch sets the PR_SET_DUMPABLE capability before switching to a unprivileged user to allow core dumps (see also the paragraph about set-user-ID in `man 5 core`) Background: While debugging bird on Alpine we wonder why it was not possible to get a core dump when bird runs under a unprivileged user. Original Alpine Issue: https://gitlab.alpinelinux.org/alpine/aports/-/issues/14408 sysdep/linux/syspriv.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/sysdep/linux/syspriv.h b/sysdep/linux/syspriv.h index 8b210f06..efb1fff0 100644 --- a/sysdep/linux/syspriv.h +++ b/sysdep/linux/syspriv.h @@ -73,6 +73,10 @@ drop_uid(uid_t uid) if (prctl(PR_SET_KEEPCAPS, 1) < 0) die("prctl: %m"); + /* allow core dumps after dropping root ID */ + if (prctl(PR_SET_DUMPABLE, 1) < 0) + die("prctl: %m"); + /* completely switch to the unprivileged user ID */ if (setresuid(uid, uid, uid) < 0) die("setresuid: %m"); -- 2.30.2
On Fri, Jan 13, 2023 at 03:21:36PM +0100, Thomas Liske wrote:
Signed-off-by: Thomas Liske <liske@ibh.de> ---
This patch sets the PR_SET_DUMPABLE capability before switching to a unprivileged user to allow core dumps (see also the paragraph about set-user-ID in `man 5 core`)
Background: While debugging bird on Alpine we wonder why it was not possible to get a core dump when bird runs under a unprivileged user.
Hi Sorry for later reply. Did not know about this issue with core dumps. It is interesting nobody noticed that before. I am not really sure why using setresuid() has the same core dump restriction as set-user-ID programs, considering it changes both real and effective UID. Using prctl(PR_SET_DUMPABLE) has some strange side-effects in changing ownership of /proc/<pid>/* fields. Not really sure what are implications of that. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (2)
-
Ondrej Zajicek -
Thomas Liske