The coredump code always calls set_dumpable(0) when it starts (even
if RLIMIT_CORE prevents any core from being dumped). The effect of
this (via task_dumpable) is to make /proc/pid/* files owned by root
instead of the user, so the user can no longer examine his own
process--in a case where there
> Ugh, sorry, I was wrong. coredump_wait() initializes mm->core_done and sets
> mm->core_startup_done before checking SIGNAL_GROUP_EXIT. This means we have
> to check ->core_waiters or SIGNAL_GROUP_EXIT before calling coredump_wait().
Ah. Checking core_waiters seems like a fine thing to do.
T
On 10/11, Roland McGrath wrote:
>
> > Hmm. Actually, do we need any check? If another thread (or CLONE_VM task)
> > already started do_coredump(), we must see SIGNAL_GROUP_EXIT when we take
> > ->mmap_sem. In that case coredump_wait() does nothing but returns -EAGAIN.
>
> You're right again here.
> Do we really need the new MMF_DUMP_STARTED flag? We are holding ->mmap_sem,
> can't we check "mm->core_waiters != 0" instead?
Yes, I think you're right. I gave the old use of dumpable the benefit of
the doubt as being needed for synchronization, but that would be enough too.
> Hmm. Actually, d
On 10/10, Roland McGrath wrote:
>
> As far as I know, set_dumpable was only used in do_coredump for
> synchronization and not intended for any security purpose.
I don't understand why do_coredump() clears DUMPABLE too.
> This changes do_coredump to use a separate bit for its
> synchronization, s
The coredump code always calls set_dumpable(0) when it starts (even
if RLIMIT_CORE prevents any core from being dumped). The effect of
this (via task_dumpable) is to make /proc/pid/* files owned by root
instead of the user, so the user can no longer examine his own
process--in a case where there
6 matches
Mail list logo
