bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel

[Arnaud Panaïotis]

On 19/04/2022 16:00, Pádraig Brady wrote:
> On 19/04/2022 08:47, Arnaud Panaïotis wrote:
> > Hello,
> >
> > I did not received any feedback from this request right now. Have you
> > made any progress on this subject ?
> >
> > Please let me know the progress for this, or contact me for additional
> > information if needed.
> >
> > I'd like to have a ticket link to follow the advancement of this issue
> > (if possible). I'm available to test a patch if you are able to provide
> > me one.
> >
> > Best regards,
> >
> > On 01/04/2022 15:55, Arnaud Panaïotis wrote:
> > > Hello,
> > >
> > > I'm working for a client to generate embedded 32-bits Linux Kernel
> > > working after y2038 issue.
> > >
> > > I generated a 5.15 Kernel thought Buildroot with Coreutils 9.0, GCC
> > > 11.2.0, Binutils 2.37 and CFLAGS  -D_LARGEFILE_SOURCE
> > > -D_FILE_OFFSET_BITS=64  -D_TIME_BITS=64
> > >
> > > The Kernel pass y2038 but I found an issue with cp:
> > > After analysis, the error occurs when trying to move an empty folder
> > > without all user mode rights.
> > >
> > > Here how to reproduce:
> > >
> > > # mkdir -p test/test1 folder
> > > # chmod u-w test/test1
> > > # date -s "2040-04-02"
> > > # cp -a test/* folder/
> > > cp: setting permissions for 'folder/test1' : Value too large for
> > > defined data type
> > >
> > > Note: The folder is copied before the error occurs. The copy works
> > > fine before y2038.
> > >
> > >
> > > The issue comes from coreutils-9.0/src/cp.c
> > >
> > > Line 512 : if (lchmod (dir, stats.st_mode | S_IRWXU) != 0)
> > >
> > > FYI I had a previous issue while calling lstat function from
> > > <sys/stat.h> which is included in lib/lchmod.c. I used /usr/bin/stat
> > > as a workaround.
> > >
> > >
> > > Keep me in touch if you need more information.
>
> The original mail seems to not have hit the lists, sorry.
>
> The error suggests that the fstatat() done within lchmod()
> is using a 32 bit time_t component of the stat structure.
> Your kernel is new enough to support the 64 bit equivalent,
> but you don't mention glibc. Can you ensure you're using
> at least glibc 2.34, which added support for the 64 bit variants.
>
> coreutils is configured by default to enable use
> of the 64 bit variants where available, and you've confirmed
> this as you say both -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64 are
> defined.
>
> An strace of the cp command would be useful to confirm the problematic
> syscall.
>
> thanks,
> Pádraig

Hello,

Thanks for the quick answer.

My glibc is 2.34-9 (2.34-9-g9acab0bba6a5a57323b1f94bf95b21618a9e5aa4).

Strace attached.

Except for the stat.h, I encountered no issue with Kernel, mysql, my
application...

I indeed suspect stat.h to use a 32 bits time_t somewhere.

Regards,

--

*Arnaud PANAÏOTIS* | Lead Developer Freelance
+33 6 34 82 12 62 | arnaud.panaiotis@gmx.fr <mailto:Arnaud Panaïotis
<arnaud.panaiotis@gmx.fr>>

18 place Jean Moulin - 38000 Grenoble
APsudo - www.panaiotis.fr <https://www.panaiotis.fr>

--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

strace-cp2038.log
Description: Text document