Re: bug in fchownat in n32 and 64 ABIs

[David Daney]

On 10/27/2011 04:59 PM, Bruno Haible wrote:
> David Daney wrote:
> > > '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.
>
> Version 4.6, built with "gcc -m64", compared to version 4.5.17:
>
>
> For the program in ABI 64:
>
> strace 4.5.17 reports
> SYS_5250()                              = -1 EPERM (Operation not permitted)
>
> strace 4.6 reports nothing, it stopped the log after it saw an exit() call:
> getsockopt(1099511620912, 0xfffff820 /* SOL_??? */, 1099511625776, 0, 
> 0x5555748ed0) = 0
> svr4_syscall()                          = 5012
> exit(1099511623472)                     = ?
> fchownat: Operation not permitted
> fchownat: Operation not permitted
> fchownat: Operation not permitted
>
>
> For the program in ABI n32:
>
> strace 4.5.17 reports
> SYS_6254()                              = -1 EPERM (Operation not permitted)
>
> strace 4.6 reports
> n32_inotify_add_watch(0xffffffffffffff9c, 0x10000a30, 0xffffffff) = -1 EPERM 
> (Operation not permitted)
> n32_inotify_add_watch(0xffffffffffffff9c, 0x10000a30, 0x4f0) = -1 EPERM 
> (Operation not permitted)
> n32_inotify_add_watch(0xffffffffffffff9c, 0x10000a30, 0xffffffff) = -1 EPERM 
> (Operation not permitted)
>
>
> For the program in ABI 32:
>
> strace 4.5.17 reports
> fchownat(AT_FDCWD, "foo.c", -1, 1264, 0) = 0
> fchownat(AT_FDCWD, "foo.c", 1264, -1, 0) = 0
> fchownat(AT_FDCWD, "foo.c", -1, -1, 0)  = 0
>
> strace 4.6 reports
> o32_fchownat(0xffffffffffffff9c, 0x400b00, 0xffffffffffffffff, 0x4f0, 0) = 0
> o32_fchownat(0xffffffffffffff9c, 0x400b00, 0x4f0, 0xffffffffffffffff, 0) = 0
> o32_fchownat(0xffffffffffffff9c, 0x400b00, 0xffffffffffffffff, 
> 0xffffffffffffffff, 0) = 0
>
>
> These traces reveal that
>    - in ABI 32 (the case that works) the value (uid_t)-1 is being passed
>      to the kernel as 0xffffffffffffffff,
>    - in ABI n32 (the case that fails) the value (uid_t)-1 is being passed
>      to the kernel as 0x00000000ffffffff.
>
> Note that 'uid_t' is 'unsigned int' in userland.

Your test program works find for me under both n32 and n64 ABIs, so I 
think you must have either an obsolete kernel or obsolete glibc (or 
perhaps both).  Perhaps you should consider upgrading your system.

David Daney