From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 00:51:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7AB416A4CE for ; Wed, 18 Feb 2004 00:51:02 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31CA443D2F for ; Wed, 18 Feb 2004 00:51:02 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i1I8oqwn009568; Wed, 18 Feb 2004 09:50:58 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Bruce Evans From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 18 Feb 2004 14:18:59 +1100." <20040218140756.S20006@gamplex.bde.org> Date: Wed, 18 Feb 2004 09:50:52 +0100 Message-ID: <9567.1077094252@critter.freebsd.dk> cc: current@freebsd.org Subject: Re: standard error handling for malloc() broken for user root and group wheel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2004 08:51:03 -0000 In message <20040218140756.S20006@gamplex.bde.org>, Bruce Evans writes: >User root and group wheel cannot get standard error handling for malloc() >even if they specifically asked for it using MALLOC_OPTIONS=a or >equivalent. This was broken in rev.1.73 of malloc.c. Fix: The situations which can result in the 'a' vs 'A' flag making a difference in malloc(3) behavior are all violations of the malloc(3) API as defined by ISO C and as such the standard defines the behaviour as "undefined". Talking about a "standard error handling" in this context is therefore at best confused, at worst misleading. Now, if we can agree that we talk about "API violation handling", which in less convoluted terms are called "bugs", we can discuss what we think the proper behaviour is. The commit message for 1.73 states my rationale for the current handling very precisely: For "sensitive" processes, we always set the 'A' flag which causes abort() to be called on first sight of trouble. "sensitive" is somewhat arbitrarily defined as "setuid, setgid, uid == root or gid == wheel". The 'A' option carries no performance penalty. It is not possible to override this setting: fix the program instead. Given that we have run with this change for a year now, and given that there still have not been shown one single real-world application which gets into trouble by this, I am not inclined to loosen up the current behaviour Seen in hindsight, I should have made 'A' the overall default and 'a' the optional mode, because the reason for the existence of the choice in the first place was to give users a hand when they try to survive with badly written third-party software. In fact, given the almost universal absense of third-party binary software, and the hostility and sofistication of current attacks on security, I am almost convinced that the correct thing to do is to discontinue 'a' entirely and make 'A' mandatory for all programs. Any objections to that ? Poul-Henning >Related unfixed bugs: >- the special handling for sensitive processes is not documented in malloc.3. >- the special handling for sensitive processes doesn't work in all cases. > Processes may become sensitive after malloc() has been initialized. >- the special handling for sensitive processes is not in RELENG_4. This is > only a bug if the special handling is not a bug. The first two of these have been added to my todo list. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.