Hi Alan, I could only find 3 places that reset the flag to PR_SET_DUMPABLE... I was wondering if the control flows into mgmt/LocalManager.cc (removeRootPriv(), restoreRootPriv()... as main() calls listenForProxy() after calling setup_coredump()) and other places that calls seteuid but without resetting PR_SET_DUMPABLE would affect the core dump flag.
(I've joined this list for a while but still haven't have time to hack the Traffic Server code - so this is the first time I really read the TS code... I'm usually too busy with the Open Grid Scheduler project). Or just set sysctl and see if traffic server dumps core or not, if it does then it should be this issue and we can just add the missing PR_SET_DUMPABLE calls. If not, then it is something else on your system. (It is an easy hack but we don't need to enable it permanently.) Rayson On Sat, Aug 27, 2011 at 12:13 PM, Alan M. Carroll <a...@network-geographics.com> wrote: > Saturday, August 27, 2011, 10:01:19 AM, you wrote: > >> There's also the setuid(2)/seteuid(2)/setguid(2)/seteguid(2) issue on >> Linux (the kernel does not dump core setXid programs). > > I saw that but thought it meant only setuid at the file system level. > However, ATS uses > > prctl(PR_SET_DUMPABLE, 1, 0, 0, 0); > > presumably to get around that problem. I checked the return value and it > claims to have executed correctly. However, perhaps I changed the ordering > too much when I fixed the libcap problems. Definitely something to check. > >> 2) There is also a easier (but a bit less secure way), and enabling it >> could cause sensitive data to be dumped to disk as it is a system-wide >> setting: > >> # sysctl -w kernel.core_setuid_ok=1 > > I'll keep that in mind, although as you write that's a much less preferable > solution. > > -- Rayson ================================================== Open Grid Scheduler - The Official Open Source Grid Engine http://gridscheduler.sourceforge.net/
