What were you trying to do that didn't work?

It appears that when executing cpan -h or cpan -l which looks like "read-only" operations, the command create directories because it has to initialize.
The directories being created are /root/.cpan but also system directories /usr/local/share/perl5 and /usr/local/lib64/perl5.
Creating these two system directories is extremely problematic, because it can break the Perl installation, especially if the umask is 0077.
This leads to getting 700 directories which cannot be read by users executing perl, causing havoc.
This issue was initially hit by Qualys people in their recent reported incident which hit RHEL customers (Qualys incident)

What is the impact of this issue to you?

High since user's Perl installation break.

Please provide the package NVR for which the bug is seen:

How reproducible is this bug?:

perl-CPAN-2.29-3.el9.noarch

Steps to reproduce

1. Cleanup CPAN

   # rm -fr /root/.cpan /usr/local/share/perl5 /usr/local/lib64/perl5

2. As a user create a dummy perl script

   $ cat hello.pl 
   #!/usr/bin/perl
   use strict;
   use warnings;
   print("Hello World\n");
   

3. As a user, confirm it runs fine

    $ perl hello.pl
   Hello World

4. As root, execute cpan -h or cpan -l while having a restrictive umask

   # umask 0077
   # cpan -l

5. As a user, try executing the dummy script again

   $ perl hello.pl

Expected results

Hello World

Actual results

Can't locate strict.pm:   /usr/local/lib64/perl5/strict.pm: Permission denied at hello.pl line 3.
BEGIN failed--compilation aborted at hello.pl line 3.

System directories got created with non-readable permissions:

# ls -ld /usr/local/share/perl5 /usr/local/lib64/perl5
drwx------. 2 root root 6 Jan 31 17:16 /usr/local/lib64/perl5
drwx------. 2 root root 6 Jan 31 17:16 /usr/local/share/perl5