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

[GNU bug Tracking System]

Your message dated Wed, 27 Apr 2022 17:42:47 +0100
with message-id <3c7a9382-6d04-3fdf-685d-c5c66f91f024@draigBrady.com>
and subject line Re: bug#55023: Issue with CP empty folder after y2038 on 
32-bits Kernel
has caused the debbugs.gnu.org bug report #55023,
regarding Issue with CP empty folder after y2038 on 32-bits Kernel
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
55023: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55023
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems

--- Begin Message --- Subject: Re: Issue with CP empty folder after y2038 on 32-bits Kernel Date: Tue, 19 Apr 2022 09:47:25 +0200 User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0

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.

--

Arnaud PANAÏOTIS | Lead Developer Freelance
+33 6 34 82 12 62 | arnaud.panaiotis@gmx.fr

18 place Jean Moulin - 38000 Grenoble - France
APsudo - www.panaiotis.fr

--

Arnaud PANAÏOTIS | Lead Developer Freelance
+33 6 34 82 12 62 | arnaud.panaiotis@gmx.fr

18 place Jean Moulin - 38000 Grenoble
APsudo - www.panaiotis.fr

---

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

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#55023: Issue with CP empty folder after y2038 on 32-bits Kernel
>
>
>
>
> Date: 
>
> Wed, 27 Apr 2022 17:42:47 +0100
>
>
>
>
> User-agent: 
>
> Mozilla/5.0 (X11; Linux x86_64; rv:97.0) Gecko/20100101 Thunderbird/97.0
>
>
>
>
> Marking this as done in the coreutils bug tracker,
> now that this is being tracked in glibc.
>
> thank you!
>
> On 27/04/2022 13:46, Adhemerval Zanella wrote:
>
> > > > > > > On 21/04/2022 14:36, Pádraig Brady wrote:
> > > > > > > > That suggests the kernel (statx) returns fine,
> > > > > > > > but glibc's fstatat64 is returning the EOVERFLOW.
>
> > It seems to be a glibc missing support indeed.  The coreutils issues indicates
> > that lchmodat failed somehow:
> >
> >                if (lchmodat (dst_dirfd, dst_relname, dst_mode | S_IRWXU) != 0)
> >                  {
> >                    error (0, errno, _("setting permissions for %s"),
> >                           quoteaf (dst_name));
> >                    goto un_backup;
> >                  }
> >
> > And lchmodat is a gnulib wrapper for fchmodat:
> >
> > CHMODAT_INLINE int
> > lchmodat (int fd, char const *file, mode_t mode)
> > {
> >    return fchmodat (fd, file, mode, AT_SYMLINK_NOFOLLOW);
> > }
> >
> > And since Linux fchmodat syscall does not provide a 'flag' argument (to
> > handle AT_SYMLINK_NOFOLLOW), glibc emulates it through opening a procfs file
> > descriptor, issuing fstatat to check if it is link (since some kernels and
> > filesystem it returns in inconsistent results), and then issue chmod.
> >
> > However, the glibc internal fstat does not use the 64-bit version, which
> > then results in EOVERFLOW.
> >
> > I have opened https://sourceware.org/bugzilla/show_bug.cgi?id=29097 and I will
> > fix it upstream and backport to 2.34 and 2.35.
>
>
>
> --- End Message ---