0

My CPU is of type armhf, so 32-bit. I run Linux Kernel 5.4 on it (so it supports 64-bit time_t for 32-bit system). I compile programs against glibc 2.34 (so time_t can be explicitely set to be 64-bit instead of 32-bit).

Now I am trying to get this simple piece of code working (test.c).

#include <stdio.h>
#include <sys/stat.h>
#include <string.h>
#include <errno.h>

int main()
{
    int ret = 0;
    ret = lchmod ("/tmp/testme.file", 0755);
    printf("ret=%d; errno=%d, strerror=%s\n", ret, errno, strerror(errno));
    return 0;
}

(Cross-)Compile it like so:

arm-linux-gnueabihf-gcc -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 test.c -o test

To test the program I set my system date to 2084-01-01 (beyond year 2038 is important). Then I create a file by running touch /tmp/testme.file. This file gets a creation timestamp of 2084-01-01. Now when I run the above code ./test it gives me this error message:

ret=-1; errno=75, strerror=Value too large for defined data type

It seems Value too large for defined data type error happens because the function lchmod(...) cannot handle files with creation timestamps beyond year 2038.

Why is this? Is this a glibc bug or does the glibc 2.34 itself has to be re-compiled with additional CFLAGS -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64.

When I change lchmod(...) to chmod(...) it works.

arminb
  • 2,036
  • 3
  • 24
  • 43
  • `lchmod` ? Is `/tmp/testme.file` a symLink? `./test it gives me this error message:` What the value of `ret` and the value or `errno`? – KamilCuk Dec 09 '21 at 15:42
  • @KamilCuk no it's not. BTW if I change `lchmod(...)` to `chmod(...)` it works. I tend to believe this is a glibc 2.34 bug. – arminb Dec 09 '21 at 15:44
  • This is overall odd - `lchmod` should fail with `ENOSYS`, it should not succeed, it's not available on Linux, and (99% of the time) you can't set permissions on symlinks, so it's pointless. Does compiling without any `-D_FILE...` macros makes `lchmod` suceeded? Please also add `errno = 0` before the call to `lchmod`. || Och, I see it was just implemented - https://sourceware.org/pipermail/glibc-cvs/2020q1/068786.html . Could you call `fchmodat (AT_FDCWD, "/tmp/testme.file", 0755 AT_SYMLINK_NOFOLLOW);` And see if you have same error? Same error without `AT_SYMLINK_NOFOLLOW`? – KamilCuk Dec 09 '21 at 16:00
  • I found several links where this might be related to -D_FILE_OFFSET_BITS=64 missing. As this I believe you have to recompile your libc. But if this is part of file system structure, you also need to update file system kernel things as well? – Klaus Dec 09 '21 at 16:06
  • @KamilCuk `test.c` without `-D_FILE...` fails also when executed. Calling `fchmodat` with `AT_SYMLINK_NOFOLLOW` set FAILS. Calling `fchmodat` **without** `AT_SYMLINK_NOFOLLOW` set SUCCEEDS. Basically it behave like `lchmod` and `chmod`. – arminb Dec 09 '21 at 16:14
  • What filesystem are you running on? I _guess_ you are triggering this : https://elixir.bootlin.com/linux/latest/source/fs/open.c#L1389 . That's the single EOVERFLOW I can see there :/ – KamilCuk Dec 09 '21 at 16:55
  • Is `__NR_lchmod` defined? https://code.woboq.org/userspace/glibc/sysdeps/unix/sysv/linux/fchmodat.c.html#34 Please _do not_ check on crosscompiler - check the target running linux system. Please also check if cross-compiler standard libraries are the same as on target.. is `arm-generic/errno.h` the same? Does the issue happen when _not_ crosscompiling? Please add `errno = 0` before callling `lchmod`. Either way, you _should_ end up in an error https://github.com/bminor/glibc/blob/77c1573dbceebf75203e4201615def9765599d87/sysdeps/unix/sysv/linux/fchmodat.c#L35 , the suprising part is `errno=75`. – KamilCuk Dec 09 '21 at 17:07
  • Or maybe `O_LARGEFILE` is missing in that open from here: https://github.com/bminor/glibc/blob/77c1573dbceebf75203e4201615def9765599d87/sysdeps/unix/sysv/linux/fchmodat.c#L43 . If possible, would be great if you copy that code, add `O_LARGEFILE` to that open there and see if it works then. But even so, https://github.com/bminor/glibc/blob/77c1573dbceebf75203e4201615def9765599d87/sysdeps/unix/sysv/linux/fchmodat.c#L64 will fail with `EOPNOTSUPP`, so... Why are you using `lchmod` at all? It's just not supported on linux... And sure, I think you could post a bug to glibc - it should return ENOSYS – KamilCuk Dec 09 '21 at 17:14
  • @KamilCuk in fact my demo program was just an excerpt from `coreutils`'s `mknod` source code (https://github.com/coreutils/coreutils/blob/master/src/mknod.c) At line 275 `lchmod` is called and fails. Also `mkfifo` uses `lchmod` and fails when permission parameter is set. – arminb Dec 09 '21 at 19:22
  • 1
    @arminb Yes, I understand it runs on ARMHF. It might have a micron memory chip as well. However, the underlying problem seems to be with the software stack (this is not clear at this point, but it seems like a glibc bug). Ie, if it is a glibc bug, it has nothing to do with the fact that you are running on ARMHF (nor Linux). I don't fault you that it **COULD BE** arm related. Just when you accept an answer, please remove the tag **IF** appropriate. – artless noise Dec 09 '21 at 19:29

1 Answers1

1

This is indeed a glibc bug, you want a version that includes commit 118a2aee07f64d605b6668cbe195c1f44eac6be6. That is v2.36 or newer.

Uwe Kleine-König
  • 3,426
  • 1
  • 24
  • 20