Messages in this thread | | | Date | Thu, 20 Jan 2000 02:36:40 +0100 | From | Guest section DW <> | Subject | Re: Fix struct siginfo |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |