On Sun, 2007-08-05 at 09:18 -0700, Steve G wrote: > >> Think of it, is there any reason for dhcdbd to dump core *every time* it runs? > > >> Will anyone be looking at that core dump? > > > >Fedora runs (ulimit -S -c 0) in /etc/profile, so no process doesn't dump > >core by default. > > The kernel hook is before anything decides whether or not to actually allow the > dumping of core. Its for this very reason. Most admin's will not allow core dumps > because it wastes disk space and could contain privileged information. So, people > may not be aware of the consequences of using abort() casually in a program. So, > if core dump is always turned off and we want to protect everyone...we need to > hook before that check. > > >I don't know about the specific case of dhcdbd - maybe it uses abort() > >when it should use exit(nonzero). But in general, abort() is useful > >even on production systems. > > I guess part of the issue is that glibc uses abort to bring the program to an end > - like on a double free. If there was another signal that indicated that a > program is ending due to something FORTIFY_SOURCE detected or gcc's stack > protector found, we could filter this out better. We use abort() quite extensively in samba, it is used exactly to obtain a core dump from users when asked for, for strange conditions. I don't think you can declare abort() like something applications should not use at this point, it's been used for so long. Reality is that many applications use it, for legit reasons, and I don't think you are easily going to convince upstream they shouldn't. A more sensible approach is to build application profiles like you do for SELinux, and build in a mechanism to easily shutdown alerts at the root if the admin thinks the specific pattern behavior of an application is ok. Simo. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
