Re: Fix struct siginfo

[Guest section DW <dwguest at win dot tue dot nl>]

On Wed, Jan 19, 2000 at 02:28:10PM +0000, Alan Cox wrote:

> > And glibc relied on thisall the time, have a look at
> > <bits/siginfo.h>:
> 
> Oh jeez 8)
> 
> > 	    __uid_t si_uid;	/* Real user ID of sending process.  */
> > 	  } _kill;
> > 
> > With those older kernel we loose already with glibc :-(.  
> 
> Ok
> 
> > What kind of old binaries?  glibc 2.1 has externally 32bit uids - and
> > realtime signals (which use siginfo) are not supported by libc5 AFAIK.
> 
> If libc5 doesnt support signinfo and glibc always relied on a couple of
> random numbrs being zero then ok.  I hadn't realised that glibc was using
> the unsafe values directly and getting away with it..

"If libc5 doesnt support siginfo" -

I think things are like this:
We wondered about si_uid. It is a field in a siginfo_t, which is a
parameter to sa_sigaction, which is a field in struct sigaction
which is a parameter of the sigaction system call.
This field is used only when SA_SIGINFO is set.
(There is a second use of siginfo_t, namely as parameter to the waitid() call.
Maybe this appears in the kernel only via solaris_waitid() where it uses
struct sol_siginfo, which has a 32-bit _uid field.)

The field sa_sigaction was introduced in 2.1.86.
libc4 and libc5 don't know about all this (except that the 5.2.18
includes mention sa_sigaction), certainly do not use it anywhere.
But this means that programs compiled under libc5 will have used
the kernel includes.

Also glibc-2.0.6 doesnt know about sa_sigaction, but glibc-2.1 does.

Is this used by anybody?
I did a quick grep through all sources for a certain distribution
and found si_uid used only by gdb and strace.
So, it seems that we can do whatever we want - probably very few
programs are involved, maybe only these two. (And these in a very
minor way: gdb redefines si_uid itself, strace only prints it.)

Andries