[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/45393 (core dumps are unilaterally prevented by unmounted cwd or MNT_NOCOREDUMP even if corename will be valid)
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>
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
Content-Type: text/plain; charset=US-ASCII
At Sat, 24 Sep 2011 00:30:04 +0000 (UTC), christos%zoulas.com@localhost
Subject: Re: kern/45393 (core dumps are unilaterally prevented by unmounted=
cwd or MNT_NOCOREDUMP even if corename will be valid)
> Well, I can ../../ my way out to anywhere then, so it is not a lot of he=
> 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=
> 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
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
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?
Greg A. Woods
+1 250 762-7675 RoboHack
Planix, Inc. <woods%planix.com@localhost> Secrets of the Weird
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (NetBSD)
-----END PGP SIGNATURE-----
Main Index |
Thread Index |