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

["Greg A. Woods" <woods%planix.com@localhost>]

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

From: "Greg A. Woods" <woods%planix.com@localhost>
To: NetBSD GNATS <gnats-bugs%NetBSD.org@localhost>
Cc: 
Subject: Re: kern/45393 (core dumps are unilaterally prevented by unmounted cwd 
or MNT_NOCOREDUMP even if corename will be valid)
Date: Sat, 24 Sep 2011 15:14:44 -0700

 --pgp-sign-Multipart_Sat_Sep_24_15:14:44_2011-1
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
 
 At Sat, 24 Sep 2011 00:30:04 +0000 (UTC), christos%zoulas.com@localhost 
(Christos Zou=
 las) wrote:
 Subject: Re: kern/45393 (core dumps are unilaterally prevented by unmounted=
  cwd or MNT_NOCOREDUMP even if corename will be valid)
 >=20
 >  Well, I can ../../ my way out to anywhere then, so it is not a lot of he=
 lp.
 >  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 additio=
 nal
 >  flag or weaken MNT_NOCOREDUMP.
 
 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.
 
 So, with that said I'd say yes, please close this PR (though perhaps
 your final fix deserves a pull-up to netbsd-5?)
 
 
 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.
 
 
 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?
 
 --=20
                                                Greg A. Woods
 
 +1 250 762-7675                                RoboHack 
<woods%robohack.ca@localhost>
 Planix, Inc. <woods%planix.com@localhost>      Secrets of the Weird 
<woods%weird.com@localhost>
 
 --pgp-sign-Multipart_Sat_Sep_24_15:14:44_2011-1
 Content-Type: application/pgp-signature
 Content-Transfer-Encoding: 7bit
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.9 (NetBSD)
 
 iD8DBQBOflZUZn1xt3i/9H8RApveAJ9q1THJ16tQQWXkgs6eBtK2bqlJ6gCfaYr1
 /jcBnbdBdcMsEqvSr1CDK6Q=
 =uHuJ
 -----END PGP SIGNATURE-----
 
 --pgp-sign-Multipart_Sat_Sep_24_15:14:44_2011-1--