Date: Mon, 08 Oct 2018 15:48:39 -0700 From: Ravi Pokala <rpokala@freebsd.org> To: Eugene Grosbein <eugen@grosbein.net>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: coredumps disallowed when creds are changed? Message-ID: <505EC621-4F7D-4857-A81A-38AF71909000@panasas.com> In-Reply-To: <2e5b1b34-7bd7-f1b8-4f6a-9c794402d2c4@grosbein.net> References: <D0A57A0A-5416-44ED-B5C8-2FC5B45B6BCB@freebsd.org> <2e5b1b34-7bd7-f1b8-4f6a-9c794402d2c4@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
-----Original Message----- From: Eugene Grosbein <eugen@grosbein.net> Date: 2018-10-08, Monday at 15:33 To: Ravi Pokala <rpokala@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: coredumps disallowed when creds are changed? > 09.10.2018 4:31, Ravi Pokala wrote: > >> Greetings hackers. >> >> core(5) states: >> >>> By default, a process that changes user or group credentials >>> whether real or effective will not create a corefile. >>> This behaviour can be changed to generate a core dump by setting the sysctl(8) variable kern.sugid_coredump to 1. >> >> Can someone explain why? > > Real/effective user/group id often are changed for a process started > by non-privilegied user running set[ug]id binary like csh/chpass/passwd(1) > that can read sensitive system data similar to /etc/master.passwd > containing password hashes. If such utility reads sensitive data > and then crashes due to a bug, its coredump may leak data to unexpected places > of file system like /home partition, then go to a dump/backup of file system, > get uploaded offsite as part of backup etc. That should not happen by default. That makes perfect sense. Thanks Eugene! -Ravi (rpokala@)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?505EC621-4F7D-4857-A81A-38AF71909000>