On Tue, Aug 06, 2019 at 05:27:54AM -0600, Warren Young wrote:> On Aug 5, 2019, at 6:57 PM, Fred Smith <fredex at fcshome.stoneham.ma.us> wrote: > > > > no core file (yes, ulimit is configured)yeah, I meant "ulimit -c unlimited" is in effect. I had no idea systemd had made such a drastic change. 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. but thanks for the details! Fred> > That?s nowhere near sufficient. To restore classic core file dumps on CentOS 7, you must: > > 1. Remove Red Hat?s ABRT system, which wants to catch all of this and handle it directly. Say something like ?sudo yum remove abrt*? > > > 2. Override the default sysctl telling where core dumps land by writing this file, /etc/sysctl.d/10-core.conf: > > kernel.core_pattern = /tmp/core-%e-%p > kernel.core_uses_pid = 1 > fs.suid_dumpable = 2 > > Then apply those settings with ?sudo sysctl ?system?. > > I don?t remember what the default is, which this overrides, but I definitely didn?t want it. > > You can choose any pattern you like, just remember what permissions the service runs under, because that?s the permission needed by the process that actually dumps the core to make the file hit the disk. That?s why I chose /tmp in this example: anyone can write there. > > > 3. Raise the limits by writing the following to /etc/security/limits.d/10-core.conf: > > * hard core unlimited > * soft core unlimited > > If this is what you meant by ?ulimit,? then great, but I suspect you actually meant ?ulimit -c unlimited?, but I believe until you do the above, the ulimit CLI app can have no effect. You have to log out and back in to make this take effect. > > Once the above is done, ?ulimit -c unlimited? can take effect, but it?s of no value at all in conjunction with systemd services, for example, since those don?t run under a standard shell, so your .bash_profile and such aren?t even exec?d. > > > 4. If your program is launched via systemd, then you must edit /etc/systemd/system.conf and set > > DefaultLimitCORE=infinity > > then say ?sudo systemctl daemon-reeexec? > > Case matters; ?Core? won?t work. Ask me how I know. :) > > > 5. If you have a systemd unit file for your service, you have to set a related value in there as well: > > LimitCore=infinity > > You need both because #4 sets the system-wide cap, while this sets the per-service value, which can go no higher than the system cap. > > > 6. Restart the service to apply the above two changes. > > > Yes, it really is that difficult to enable classic core dumps on CentOS 7. You?re welcome. :) > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos-- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- "For him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy--to the only God our Savior be glory, majesty, power and authority, through Jesus Christ our Lord, before all ages, now and forevermore! Amen." ----------------------------- Jude 1:24,25 (niv) -----------------------------
On Aug 6, 2019, at 7:59 AM, Fred Smith <fredex at 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 <fredex at 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.
On Tue, Aug 06, 2019 at 03:18:06PM -0600, Warren Young wrote:> On Aug 6, 2019, at 7:59 AM, Fred Smith <fredex at 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 <fredex at 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.Oh of course. duh! What we've alwayws done with this program is to put "ulimit -c unlimited" in the script that sets its environment then starts the program itself. that minimizes the attack surface. Setting up as you described earlier, is there a way to allow only a single program to drop core? -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- "For him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy--to the only God our Savior be glory, majesty, power and authority, through Jesus Christ our Lord, before all ages, now and forevermore! Amen." ----------------------------- Jude 1:24,25 (niv) -----------------------------