Discussion:
'getgroups' syscall does not work with kernel 2.6.34
i***@arcor.de
2010-05-19 09:12:57 UTC
Permalink
Hi,

I've just updated to the new linux kernel 2.6.34 and I've noticed that
there is a problem with the system call 'getgroups()': it returns a -1
and 'errno' is set to 38.
Here is a simple test program:

#include <unistd.h>
#include <errno.h>

int main(int argc, char *argv[])
{
int res;

res = getgroups(0,NULL);

if(res < 0)
return errno;

return 0;
};

# ./test
# echo $?
38
#

The same test program works as expected when linked against the glibc.
I've run the test on both an i386 and an arm platform with the same results.

giorgio


Giorgio, ***@arcor.de
i***@arcor.de
2010-05-19 16:19:52 UTC
Permalink
----- Original Nachricht ----
Von: Indan Zupancic <***@nul.nu>
An: ***@arcor.de
Datum: 19.05.2010 13:14
Betreff: Re: 'getgroups' syscall does not work with kernel 2.6.34
Hello,
Post by i***@arcor.de
Hi,
I've just updated to the new linux kernel 2.6.34 and I've noticed that
there is a problem with the system call 'getgroups()': it returns a -1
and 'errno' is set to 38.
#include <unistd.h>
#include <errno.h>
int main(int argc, char *argv[])
{
int res;
res = getgroups(0,NULL);
if(res < 0)
return errno;
return 0;
};
# ./test
# echo $?
38
#
The same test program works as expected when linked against the glibc.
I've run the test on both an i386 and an arm platform with the same
results.
38 is ENOSYS, meaning that somewhere somehow the wrong syscall number is
used.
Dietlibc 0.35 works for me with linux 2.6.34-rc6.
What Dietlibc version are you using?
$ strace ./t
execve("./t", ["./t"], [/* 49 vars */]) = 0
open("/dev/urandom", O_RDONLY) = 3
read(3, "\212\n\302J", 4) = 4
close(3) = 0
set_thread_area({entry_number:-1 -> 6, base_addr:0x8049254, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0, useable:1}) = 0
getgroups(0, NULL) = 2
_exit(2) = ?
(I changed it to return ret.)
Greetings,
Indan
Hi,

I'm using the cvs repository.

strace is actually a good idea... :-)

Here is the strace for the dietlibc test version:
root [ /tmp ]# strace ./test
execve("./test", ["./test"], [/* 31 vars */]) = 0
set_thread_area({entry_number:-1 -> 6, base_addr:0xbff2c3b0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
getgroups(0, NULL) = -1 ENOSYS (Function not implemented)
_exit(38) = ?

and here the glibc 2.11.1 version:
execve("./test", ["./test"], [/* 31 vars */]) = 0
brk(0) = 0x86cc000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb783a000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=71959, ...}) = 0
mmap2(NULL, 71959, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7828000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0m\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1724047, ...}) = 0
mmap2(NULL, 1489160, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb76bc000
mmap2(0xb7822000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x166) = 0xb7822000
mmap2(0xb7825000, 10504, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7825000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb76bb000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb76bb6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb7822000, 8192, PROT_READ) = 0
mprotect(0xb785b000, 4096, PROT_READ) = 0
munmap(0xb7828000, 71959) = 0
getgroups32(0, NULL) = 1
exit_group(0) = ?


glibc calls actually 'getgroups32()', dietlibc calls 'getgroups()'.

I verified that if I force dietlibc to call 'getgroups32()' instead of 'getgroups()' than it works.

The problem is now I've done this test with kind of a hack; just modifying the source file:

<dietlibc>/syscalls.s/getgroups.S

to:
#include "syscalls.h"

syscall(getgroups32,getgroups)

Maybe Felix knows here the correct patch.

giorgio


Giorgio, ***@arcor.de
Felix von Leitner
2010-05-21 00:56:00 UTC
Permalink
Post by i***@arcor.de
The same test program works as expected when linked against the glibc.
I've run the test on both an i386 and an arm platform with the same results.
Return 0 here, both on i386 and amd64.
What gives?

Felix
i***@arcor.de
2010-05-21 07:58:32 UTC
Permalink
----- Original Nachricht ----
Von: Felix von Leitner <felix-***@fefe.de>
An: ***@fefe.de
Datum: 21.05.2010 02:56
Betreff: Re: 'getgroups' syscall does not work with kernel 2.6.34
Post by i***@arcor.de
Post by i***@arcor.de
The same test program works as expected when linked against the glibc.
I've run the test on both an i386 and an arm platform with the same
results.
Return 0 here, both on i386 and amd64.
What gives?
Felix
Hi,

I think I don't understand exactly your question.
On which kernel do you test? To see the problem you MUST run the new kernel >= 2.6.34,
on older kernels it works.

giorgio


Giorgio, ***@arcor.de
Felix von Leitner
2010-05-21 19:23:04 UTC
Permalink
Post by i***@arcor.de
On which kernel do you test? To see the problem you MUST run the new kernel >= 2.6.34,
I used 2.6.34. The stock one. Maybe you use a distro version that
changed something?

Felix
i***@arcor.de
2010-05-22 17:06:29 UTC
Permalink
----- Original Nachricht ----
Von: Felix von Leitner <felix-***@fefe.de>
An: ***@fefe.de
Datum: 21.05.2010 21:23
Betreff: Re: 'getgroups' syscall does not work with kernel 2.6.34
Post by i***@arcor.de
Post by i***@arcor.de
On which kernel do you test? To see the problem you MUST run the new
kernel >= 2.6.34,
I used 2.6.34. The stock one. Maybe you use a distro version that
changed something?
Felix
OK,

finally I found the point.
When I compiled the new kernel I tried disabling support for the 16 bit
UID system calls, just to see what would happen and then I just forgot
about it.

giorgio


Giorgio, ***@arcor.de

Loading...