NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: "Real programs dump core" (Hauke Fath) writes:

>>     13 EACCES Permission denied.  An attempt was made to access a file in a
>>             way forbidden by its file access permissions.

>That's tough to decipher without a core.

I don't think a core tells you the current directory of the process.

>Would a setuid root binary dump
>core as root, or as the invoking uid?

AFAIK, the dump occurs as the effective user.

>>     27 EFBIG File too large.  The size of a file exceeded the maximum.  (The
>>             system-wide maximum file size is 2**63 bytes.  Each file system
>>             may impose a lower limit for files contained within it).

EFBIG is also reported when the dump would exceed the core dump limit.

         * Refuse to core if the data + stack + user size is larger than
         * the core dump limit.  XXX THIS IS WRONG, because of mapped
         * data.
        if (USPACE + ctob(vm->vm_dsize + vm->vm_ssize) >=
            p->p_rlimit[RLIMIT_CORE].rlim_cur) {
                error = EFBIG;          /* better error code? */

>% /root/sudo-1.7.7 /usr/bin/true
>Bus error
>% limit | grep file
>filesize     unlimited

sudo sets its own coredump limit:

#if defined(RLIMIT_CORE) && !defined(SUDO_DEVEL)
     * Turn off core dumps.
    (void) getrlimit(RLIMIT_CORE, &corelimit);  
    memcpy(&rl, &corelimit, sizeof(struct rlimit));
    rl.rlim_cur = 0;
    (void) setrlimit(RLIMIT_CORE, &rl);
#endif /* RLIMIT_CORE && !SUDO_DEVEL */

>>I wonder if we should have an equivalent for kern.coredump.setid.path for
>>non-setid images.

There is:
kern.defcorename = %n.core
proc.curproc.corename = %n.core

                                Michael van Elst
                                "A potential Snark may lurk in every tree."

Home | Main Index | Thread Index | Old Index