On 10/27/2011 12:07 PM, Bruno Haible wrote:
Hi Linux/MIPS folks,
Found this bug by running the gnulib POSIX test suite: In the fchownat()
call, an uid_t or gid_t of value (uid_t)-1 or (gid_t)-1 means no change.
See<http://pubs.opengroup.org/onlinepubs/9699919799/functions/fchownat.html>.
This value is correctly recognized on all Unices, _except_ Linux/MIPS
in n32 and 64 ABIs.
[...]
$ gcc -Wall -mabi=64 foo.c
$ ./a.out ; echo $?
fchownat: Operation not permitted
fchownat: Operation not permitted
fchownat: Operation not permitted
14
$ gcc -Wall -mabi=n32 foo.c
$ ./a.out ; echo $?
fchownat: Operation not permitted
fchownat: Operation not permitted
fchownat: Operation not permitted
14
$ gcc -Wall -mabi=32 foo.c
$ ./a.out ; echo $?
Other relevant data:
- kernel version is 2.6.27.1
- glibc version is 2.7
- gcc version is 4.3.2 (Debian).
Debian doesn't support 64-bit ABIs, so this list is incomplete. Where
did you get your 64-bit libc ?
'strace' of this program shows that the system call that returns with -1/EPERM
is a call to SYS_6254 (in n32 ABI) or SYS_5250 (in 64 ABI).
Can you get strace -- version 4.5.20 or later and build it for the
corresponding ABI? That should properly decode the relevant syscalls.
Once you have that, you might post the strace output.
In the mean time I might give it a try with my 2.9 glibc on a 2.6.32.27
kernels.
David Daney
