Messages in this thread | | | Date | Wed, 19 Jan 2000 15:24:00 +0100 | From | Jakub Jelinek <> | Subject | Re: [PATCH] Security fixes for rt signals, siginfo posting |
| |
On Wed, Jan 19, 2000 at 02:04:08PM +0000, Alan Cox wrote: > > BTW: When hacking on the patch, I found that on i386 glibc defines siginfo_t > > to have a 32bit uid in the place of kernel's 16bit (but the kernel has > > padding there), which leads me to the question: is it really necessary to > > keep _kill._uid on intel with 16bit type and introduce _kill._uid32? > > You answered that question yourself. The other two bytes are undefined on > older kernels
They are undefined, yet should be cleared by the kernel which the kernel usually does not clear. With 2.3.39 and prior kernels, all glibc programs using si_uid get broken values (because glibc uses a 32bit type for si_uid and thus gets usually upper 16 bits of id garbage - running my siginfotest.c on glibc gives me bogus si_uid like -939655168) and as I have not seen anybody complaining about this, it makes me think not too many programs are actually using it so far, especially libc5. So the question is whether to fix current glibc programs, make things less complicated and break libc5 (well, breaking means worst that on a system with uids above 65535 you get the value truncated with old libc5 program, recompilation helps) or leave the ._uid32 stuff in and keep glibc programs broken and have to teach new glibc/libc5 programs about larger uids which are somewhere else in the structure.
Cheers, Jakub ___________________________________________________________________ Jakub Jelinek | jakub@redhat.com | http://sunsite.mff.cuni.cz/~jj Linux version 2.3.40 on a sparc64 machine (1343.49 BogoMips) ___________________________________________________________________
- 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/
| |