This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

_NR_setgroups32 on 2.4.x SPARC64 / 32-bit userspace and setgroups.c

sysdeps/unix/sysv/linux/sparc/setgroups.c includes
sysdeps/unix/sysv/linux/i386/setgroups.c. This includes
the fragment

#if __ASSUME_32BITUIDS > 0
      return INLINE_SYSCALL (setgroups32, 2, n, CHECK_N (groups, n));

where __ASSUME_32BITUIDS is 1 on all 2.4.x kernels.

Unfortunately, the SPARC64 kernel headers --- unlike the SPARC32 ones
--- state that setgroups32 is not defined (presumably because setgroups
is always 32-bit in 64-bit userspace and the setgroups16() wrapper in
arch/sparc64/kernel/sys_sparc32.c provides the 16-bit one for 32-bit

Obviously using the sparc32 kernel headers would fix this, but those
kernel headers are gently rotting and don't actually correspond to the
running kernel at all. I'd call this a kernel bug (as 16-bit and 32-bit
UID syscalls *are* provided in 32-bit userspace) except that there is
surely no promise that sparc64 kernel headers correspond to what is
seen in a *32-bit* userspace; and since in the 64-bit userspace there
*is* indeed no setgroups32 syscall...

I've tried to find places where the other divergences in the 32/64-bit
syscall list (lstat64(), setuid(), fstat64()...) are worked around, but
I've found no glue code to implement those, and the system didn't get as
far as building them before it failed because of the lack of
setgroups32(). So I'm forced to assume that these would implode too :(

What am I missing?

		} else {	/* else pty, not pts */

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]