bug in fchownat in n32 and 64 ABIs

bug in fchownat in n32 and 64 ABIs

[Bruno Haible]

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.

How to reproduce:
==================================== foo.c ====================================
#define _GNU_SOURCE 1
#include <fcntl.h>
#include <stdio.h>
#include <sys/stat.h>
#include <unistd.h>
int
main ()
{
  const char *filename = "foo.c";
  struct stat statbuf;
  int ret;
  int result = 0;

  ret = stat (filename, &statbuf);
  if (ret < 0)
    {
      perror ("stat");
      return 1;
    }
  else
    {
      ret = fchownat (AT_FDCWD, filename, (uid_t)-1, statbuf.st_gid, 0);
      if (ret < 0)
        {
          perror ("fchownat");
          result |= 2;
        }
      ret = fchownat (AT_FDCWD, filename, statbuf.st_uid, (gid_t)-1, 0);
      if (ret < 0)
        {
          perror ("fchownat");
          result |= 4;
        }
      ret = fchownat (AT_FDCWD, filename, (uid_t)-1, (gid_t)-1, 0);
      if (ret < 0)
        {
          perror ("fchownat");
          result |= 8;
        }
    }
  return result;
}
===============================================================================
$ 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).

'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).

Bruno
-- 
In memoriam Helmuth Hübener <http://en.wikipedia.org/wiki/Helmuth_Hübener>

Re: bug in fchownat in n32 and 64 ABIs

[David Daney]

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

Re: bug in fchownat in n32 and 64 ABIs

[David Daney]

On 10/27/2011 12:26 PM, David Daney wrote:
> 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.
>

n64 seems to work for me.  Witness:

# strace ./fchownat-test
execve("./fchownat-test", ["./fchownat-test"], [/* 6 vars */]) = 0
brk(0)                                  = 0x12a14b000
uname({sys="Linux", node="(none)", ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x5558e31000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or 
directory)
open("/etc/ld.so.cache", O_RDONLY)      = -1 ENOENT (No such file or 
directory)
open("/lib64/tls/octeon/libc.so.6", O_RDONLY) = -1 ENOENT (No such file 
or directory)
stat("/lib64/tls/octeon", 0xffffc9db70) = -1 ENOENT (No such file or 
directory)
open("/lib64/tls/libc.so.6", O_RDONLY)  = -1 ENOENT (No such file or 
directory)
stat("/lib64/tls", 0xffffc9db70)        = -1 ENOENT (No such file or 
directory)
open("/lib64/octeon/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or 
directory)
stat("/lib64/octeon", 0xffffc9db70)     = -1 ENOENT (No such file or 
directory)
open("/lib64/libc.so.6", O_RDONLY)      = 3
read(3, 
"\177ELF\2\2\1\0\0\0\0\0\0\0\0\0\0\3\0\10\0\0\0\1\0\0\0\0\0\3Wx"..., 
832) = 832
lseek(3, 59248, SEEK_SET)               = 59248
read(3, 
"\0\0\0\4\0\0\0\20\0\0\0\1GNU\0\0\0\0\0\0\0\0\2\0\0\0\6\0\0\0\n", 32) = 32
fstat(3, {st_mode=S_IFREG|0555, st_size=1680968, ...}) = 0
mmap(NULL, 1604224, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 
0) = 0x5558e43000
mprotect(0x5558fa7000, 61440, PROT_NONE) = 0
mmap(0x5558fb6000, 69632, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x163000) = 0x5558fb6000
mmap(0x5558fc7000, 14976, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x5558fc7000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x5558e32000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x5558e33000
set_thread_area(0x5558e39b00)           = 0
mprotect(0x5558fb6000, 53248, PROT_READ) = 0
mprotect(0x5558e40000, 4096, PROT_READ) = 0
stat("foo.c", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
fchownat(AT_FDCWD, "foo.c", 4294967295, 0, 0) = 0
fchownat(AT_FDCWD, "foo.c", 55, 4294967295, 0) = 0
fchownat(AT_FDCWD, "foo.c", 4294967295, 4294967295, 0) = 0
exit_group(0)                           = ?

Re: bug in fchownat in n32 and 64 ABIs

[Bruno Haible]

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.

Bruno
-- 
In memoriam Helmuth Hübener <http://en.wikipedia.org/wiki/Helmuth_Hübener>

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