Re: kern/45393 (core dumps are unilaterally prevented by unmounted cwd or MNT_NOCOREDUMP even if corename will be valid)

[christos%zoulas.com@localhost (Christos Zoulas)]

On Sep 24, 10:15pm, woods%planix.com@localhost ("Greg A. Woods") wrote:
-- Subject: Re: kern/45393 (core dumps are unilaterally prevented by unmounte

|  After doing a little more research on the origins of MNT_NOCOREDUMP
|  (first by cgd, in NetBSD, in 1996, so far as I can tell) I'm now a lot
|  less inclined to worry about the single filesystem issue I initially
|  raised.
|  
|  Indeed, as you said, if the admin doesn't want any core dumps then
|  MNT_NOCOREDUMP is the best way to ensure that (or at least it will be
|  after your fixes are in a release :-)).
|  
|  When I originally encountered the "nocoredump" option I looked to it
|  more as a way to prevent pollution of core files in random locations,
|  not as the security mechanism as it is described in mount(8).
|  
|  However my personal goal is now met by both the logging of core dumps
|  (at least with my patch to log the directory where the core is created),
|  and the ability to contain them all to one sub-directory by giving
|  kern.defcorename a fully qualified pathname template.

Great.

|  So, with that said I'd say yes, please close this PR (though perhaps
|  your final fix deserves a pull-up to netbsd-5?)

Well, that is going to be a bit difficult because 5 is missing the simple
namei() function that I am using :-)
  
|  As a side note I find it interesting that not even OpenBSD has
|  implemented MNT_NOCOREDUMP.  In fact I don't find it anywhere other than
|  in NetBSD.
|  

I have not seen it either.

|  Oh, and one more partly related thing my research revealed:  OpenBSD
|  added a check in 2007 to prevent a core from overwriting a file owned by
|  a different user (their kern_sig.c rev. 1.96).  I think NetBSD should
|  gain this check as well, but perhaps it deserves a separate PR?

I've added it too, thanks for mentioning it.

christos