Date: Sat, 14 Sep 2002 06:45:32 -0400 From: Alan E <alane@geeksrus.net> To: FreeBSD Ports List <ports@freebsd.org> Cc: Maxim Sobolev <sobomax@freebsd.org>, Jeremy Lea <reg@freebsd.org>, FreeBSD Gnome Team <gnome@freebsd.org>, kris@obsecurity.org Subject: Re: fork bombs registering packages using <VARIABLE_RESERVED_BY_US> Message-ID: <20020914104532.GA87434@wwweasel.geeksrus.net> In-Reply-To: <20020914100947.GC87001@wwweasel.geeksrus.net> References: <20020913173752.GA53609@wwweasel.geeksrus.net> <20020913175115.GA90567@shale.csir.co.za> <20020913184701.GA75702@wwweasel.geeksrus.net> <20020914071432.GA21237@vega.vega.com> <20020914100947.GC87001@wwweasel.geeksrus.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Sep 14, 2002 at 06:09:47AM -0400, Alan E wrote: >>> I don't think it is reasonable that something as innocuous as attempting >>> to override a variable on the make command line can bring the machine to >>> its knees (although, to its credit, the kernel did not fall over). >>> >>> Personally, I thik a fork bomb coming out of a port make for *any* >>> reason whatsoever is indicative of a severe design or implementation >>> error. It just should *not* happen. >> >>Try to do `make USE_XLIB=yes install' in any x11 ports and you'll >>get the same forkbomb. Please learn how bsd.port.mk in particular and >>make(1) in general work and then we'll return to this discussion. Let me add something constructive to this... After doing custom statistical software in partnership with a Uni stats professor, I designed a multimedia banking package for kiosks, then wrote embedded software for medical devices, then spent over a decade working at 2 high profile brokerages, at one doing design and implementation of both the trading floor system and the client systems, which were also embedded systems. The common thread that runs through all these all that is that these were applications that just *could not* crash, freeze, spontaneously reboot, or anything else. These were things that had, by requirement, uptimes measured in months and years at a time (for the application itself, not just the underlying OS, such as it was in some of those cases). The point I'm trying to make is that it is possible, often necessary, to design for unexpected, "illegal", and just plain "against the rules" situations, especially when the systems take input from people, fallible as we are. We can make software robust enough to handle such conditions gracefully, even with make, where an exit with a message is much preferred to forking the system into never-never-land. It's not that hard to check for and warn of suspicious or pathological conditions when you know ahead of time what they are, as everyone in this conversation clearly does. I'll also make the point that if supplying the same value for USE_GNOME on the command line that is explicitly set 30 lines into the Makefile can cause such a disaster, then our make's multi-level precedence system for variable evaluation is fatally flawed... perhaps, since this is a general condition, it is one that make itself could check for (if nothing else, make could be made aware that it is forking-and-execing recursive copies of itself, and it could simply stop after some number, overridable by the command line, was reached). -- Alan Eldridge Unix/C(++) IT Pro, 20 yrs, seeking new employment. (http://wwweasel.geeksrus.net/~alane/resume.txt) KDE, KDE-FreeBSD Teams (http://www.kde.org, http://freebsd.kde.org/) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020914104532.GA87434>