我注意到,我的一些用户在崩溃后根本没有得到核心数据,即使他们的配置中的其他内容似乎都是正确的。
在多次阅读核心(5)手册页之后,我注意到了这一点:
如果进程正在执行进程的实际用户(组) ID以外的用户(组)所拥有的set- user ID (set-group-ID)程序,则不会产生核心转储文件。
我的守护进程不是setuid,但是在很多配置中,它都是以root启动的,如果.conf文件指定用户名,它会以通常的组合方式删除特权:
setgid(gid);
setuid(uid);当它这样做时,核转储就不再生成了。环境中的其他一切似乎都是正确的,删除这些调用(并保持为root)将使我像往常一样得到代码转储。
我试图像手册页所暗示的那样,更改“真正的”uid/gid,方法是调用不那么便携的setresgid/uid,它似乎经常被建议永久放弃特权:
setresgid(gid, gid, gid);
setresuid(uid, uid, uid);我以为这能解决问题但是..。这一点也没有改善。还是没有核心区。
哇哦..。这次又是什么?
测试代码:
#include <stdlib.h>
int main(int argc, char **argv) {
if (argc > 1) {
setgid(atoi(argv[2]));
setuid(atoi(argv[1]));
}
abort();
}用法:
./a.out作为任何用户在没有setgid/setuid的情况下中止./a.out 1000 100 (其中1000是uid,100是gid)作为根用户,以删除特权并查看核心转储不会发生。我已经在arch linux、centos 6.5和openbsd 5.3中测试了这一点。
发布于 2015-06-30 14:38:07
若要强制进程始终核心转储,请使用prctl系统调用。
prctl(PR_SET_DUMPABLE, 1, 0, 0, 0);发布于 2015-04-16 07:44:43
必须为更改其权限的应用程序启用核心转储:
echo 2 > /proc/sys/fs/suid_dumpable我建议你把它写在/etc/rc.local里。
举个例子,这就是我所拥有的:
# This is to enable debugging as a normal user, rather than root
sysctl kernel.yama.ptrace_scope=0
# This is a convenient core file pattern
# '%e' is the name of the process
# '%p' is the pid of process
sysctl kernel.core_pattern="/tmp/core.%e.%p"
# Enable dump for processes with lowered privileges
echo 2 > /proc/sys/fs/suid_dumpable
# Remove limit for the size of core files
ulimit -c unlimited编辑:
您可以查看这个整洁的库,它允许您手动将核心转储写入自定义文件:https://code.google.com/p/google-coredumper/。
我相信这正是你所需要的。
https://stackoverflow.com/questions/29667243
复制相似问题