Re: bug in fchownat in n32 and 64 ABIs

[David Daney <david.daney@cavium.com>]

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