Re: standard error handling for malloc() broken for user root and group wheel

In message <20040218140756.S20006_at_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_at_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.