On Aug 6, 2019, at 7:59 AM, Fred Smith <fre...@fcshome.stoneham.ma.us> wrote:
>
> On Tue, Aug 06, 2019 at 05:27:54AM -0600, Warren Young wrote:
>> On Aug 5, 2019, at 6:57 PM, Fred Smith <fre...@fcshome.stoneham.ma.us> wrote:
>>>
>>> no core file (yes, ulimit is configured)
>
> yeah, I meant "ulimit -c unlimited" is in effect.
That only affects the shell it’s set for, which isn’t generally important for a
service, since we no longer start services via shell scripts in the systemd
world.
> I had no idea systemd had made such a drastic change.
This isn’t a systemd change, it’s a *system* change. The only reason systemd
is involved is that it also has its own defaults, just as your shell does,
overridden by the ulimit command. Steps 1-3 remove the system limits, then 4 &
5 remove the systemd limits under that, which can affect your service, if it’s
being started via systemd.
> or is it that
> someone at RH decided to make it (nearly) impossible to do? I fail
> to see how it is beneficial to anyone to make it so hard to get
> core dump files.
Core dumps are a security risk. They’re memory images of running processes.
If you configure your server like I give in my recipe, every process that drops
core will create a world-readable file in /tmp showing that process’s memory
state, which means you can recover everything it was doing at the time of the
crash.
So, if you can find a way to make, say, PAM or sshd drop core, you’ll get live
login details in debuggable form, available to anyone who can log into that box.
You definitely want core dumps off by default.
Making core dumps enabled by default is about as sensible as enabling rsh by
default.
https://en.wikipedia.org/wiki/Remote_Shell
We stopped doing that on production servers about 20-30 years ago, for more or
less the same reason.
_______________________________________________
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
