Coredumping design error

Matthew Dillon dillon at apollo.backplane.com
Sat Feb 16 10:02:33 PST 2008


:Hello Simon,
:
:In my opinion checking for ownership is better. We are avoiding other
:possible(?) bugs e.g. allowing to read files you don't own but resides
:on a directory you own. I also noticed that non-root users trying to
:coredump on other non-root users pre-created dumps fail silently.
:
:By the way as seen in my patch, we wouldn't want to hard code != 0
:because DragonFly may implement a type enforcement system or
:authorization framework.
:
:Up to you guys. I might be missing something.
:
:Cheers,
:   Ed

    Yes, I agree, we definitely do not want to remove the file.  The reason
    is that it is possible (and likely) that a service process that forks
    may coredump multiple times, possibly even in parallel.  Possibly
    hundreds of times in parallel.  This is one reason why the coredump
    code gets an advisory lock on the file.

    My only question re: this patch is whether it will work properly
    with sysctl kern.sugid_coredump.

						-Matt





More information about the Bugs mailing list