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)]

The following reply was made to PR kern/45393; it has been noted by GNATS.

From: christos%zoulas.com@localhost (Christos Zoulas)
To: "Greg A. Woods" <woods%planix.com@localhost>, 
        NetBSD GNATS <gnats-bugs%NetBSD.org@localhost>
Cc: NetBSD Kernel Bug People <kern-bug-people%netbsd.org@localhost>, 
<wiz%NetBSD.org@localhost>
Subject: Re: kern/45393 (core dumps are unilaterally prevented by unmounted cwd 
or MNT_NOCOREDUMP even if corename will be valid)
Date: Fri, 23 Sep 2011 20:26:08 -0400

 On Sep 23,  5:18pm, woods%planix.com@localhost ("Greg A. Woods") wrote:
 -- Subject: Re: kern/45393 (core dumps are unilaterally prevented by unmounte
 
 | What Christos committed isn't exactly what I had in mind...  :-)
 
 :-)
 
 | It is now strictly obeying MNT_NOCOREDUMP, but given the prevalence of
 | single-filesystem systems, I think what I suggested makes more sense,
 | i.e. only honour MNT_NOCOREDUMP if the pathname is relative, thus
 | allowing the administrator to set an absolute pathname for one or more
 | processes (or even sometimes all of them via kern.defcorename, though
 | that choice obviates the need for setting MNT_NOCOREDUMP in the first
 | place, except as a second line of defence from accidental core
 | pollution) to allow them to dump core in a given location, and also
 | allowing a user to get a core image from their own processes upon
 | specific request, but otherwise preventing processes from normally
 | dumping in any old CWD.
 
 Well, I can ../../ my way out to anywhere then, so it is not a lot of help.
 If I am allowed to set my core-name that is. I tought about the single
 filesystem issue, and I guess you can work around the issue with either
 a vnd mount or a loopback one. I think that it is better than an additional
 flag or weaken MNT_NOCOREDUMP.
 
 | However, on second look I realize I have not yet fully explored all the
 | potential problems with ptrace().  I think it's safe the way I wrote it,
 | but I cannot yet prove it.
 
 Yes, ptrace() is problematic :-)
 
 | If so then I guess the question is whether MNT_NOCOREDUMP should reign
 | supreme, or whether there should be a way around it for special cases.
 | 
 | Personally I think that if I as the superuser set proc.blah.corename (or
 | kern.defcorename) to an absolute pathname then I want core dumps to
 | happen even if I'm silly enough to also have MNT_NOCOREDUMP set on the
 | filesystem for that location.
 | 
 | I think users should also be able to use ptrace() or proc.*.corename to
 | force a core dump to an absolute pathname (where they have sufficient
 | privilege) regardless of whether the admin has set things up to
 | generally prevent cores from dropping in random CWDs anywhere and
 | everywhere.
 
 What if the admin does not want cores anywhere?
 
 | Indeed I think MNT_NOCOREDUMP is basically a throwback to before there
 | was a way to set an absolute pathname for core files and that it could
 | be at least reduced in importance in the way I suggest, if not
 | deprecated entirely.
 
 It is still a good blunt tool that was broken for a while.
 
 | Perhaps this should be discussed with a wider audience?
 
 Sure, let's do it. Perhaps others have better ideas.
 
 christos