printf behaviour with illegal or malformed format string

[Poul-Henning Kamp]

In message <20051212191830.GD74684 at cirb503493.alcatel.com.au>, Peter Jeremy writes:

>>I'm leaning towards doing what phkmalloc has migrated to over time:
>>Make a variable which can select between "normal/paranoia" and force
>>it to paranoia for (uid==0 || gid==0 || setuid || setgid).
>>
>>If the variable is set, a bogus format string will result in abort(2).
>
>set{u,g}id programs won't dump core so just abort(2)ing leaves no
>trace of what went wrong.

That's one of the reason there is an "abort2(2)" system call in the
works which allows the program to tell syslog why it comitted suicide.

I have a patch in my inbox and I should really get it committed now.

>>If it is not set, the format string will be output unformatted in
>>the message "WARNING: Illegal printf() format string: \"...\".
>
>Since this check presumably applies to the entire *printf() family,
>where do you report the error for {s,f}printf()?

Whereever the strings was meant to go, what else can I do ?

>What do you define as an "illegal printf() format string"?  I can
>think of four possible categories:
>1) Using a nonsense value before '$', eg "%12345$d"
>2) Having an invalid modifier on a builtin conversion specifier, eg "%hf"
>3) Using an undefined conversion specified, eg '%W'
>4) Having an invalid modifier on a user-specified conversion specifier

Those are probably the primary suspects.

>The last category is particularly problematic because the glibc
>interface does not have any way to identify this error.

My current plan is to provide a better API than GLIBC and make
a couple of degraded glibc-api wrappers.

-- 
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.