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