CPAN unexpectedly changed permissions

[010101010100]

We have a Service Now discovery job that gathers SBOM related inventory. One of the commands it executes is cpan -a. This ran realiably for over a year but we recently had a new image deployed and permission changes on the account that included a new umask.

Since this was a new image, cpan -a was executed for the first time and it caused cpan to unexpectedly change the perl directory permissions with the implicit umask settings and caused some breakage. We have another customer running a similar job with Ansible.

Can we fix cpan so it is not unexpectedly changing permissions?

[michal-josef-spacek]

As I understand the umask command affects all newly created directories and files. But not changing permissions.

In examples (OS: Fedora 41):

umask 0077
cpan -a
...
Wrote bundle file
    /home/$USER/.local/share/.cpan/Bundle/Snapshot_2025_02_04_00.pm
...
ls -l /home/$USER/.local/share/.cpan/Bundle/Snapshot_2025_02_04_00.pm
-rw-------. 1 $USER $USER 168700  4. feb. у 11:00 /home/$USER/.local/share/.cpan/Bundle/Snapshot_2025_02_04_00.pm

This is fine result defined by umask command

[Tronde]

@010101010100 Did cpan -a change the directory permission or did it create the directories, because they were not existing in the new image?

To what kind of image do you refer and what directories were affected?

I'm asking these questions to determine how your observations relate to an issue I track for my customer.

[briandfoy]

cpan -a just runs the CPAN::Shell->autobundle code, which creates a file in $CPAN::Config->{cpan_home}/Bundle. I think the problem is basic system administration. CPAN should use the umask, because that's why umask exists. If you get the wrong permissions, look into the umask you are using. If that's not what you want, fix that.

This isn't really "unexpectedly" changing anything. It's respecting the account settings you chose.

[010101010100]

I appreciate you confirming this should not happen. Unfortunately, it does.

We are using the RHEL perl-CPAN package and running cpan -a changed the directory permissions to already existing directories /usr/local/lib64/perl5 and
/usr/local/share/perl5. In our case, cpan was not previously run and when invoked from a privileged account, it made the change and applied the umask of the caller causing breakage.

There is another vendor who ran into this same issue where their product tried to invoke "cpan -l" cpan also changed the permissions. I suspect these users also had never run cpan before and when their product did, it made the modifications. https://success.qualys.com/support/s/article/000007702

I think the expected behavior here is for cpan to not change the permissions to any existing directories regardless if it is the first time being run or not but this is what happens on RHEL and might happen on other distro's. I encourage you to test this and confirm the unexpected behavior.

[jplesnik]

I appreciate you confirming this should not happen. Unfortunately, it does.

We are using the RHEL perl-CPAN package and running cpan -a changed the directory permissions to already existing directories /usr/local/lib64/perl5 and /usr/local/share/perl5. In our case, cpan was not previously run and when invoked from a privileged account, it made the change and applied the umask of the caller causing breakage.

I do not know how it could happen. Because I tried this scenario as root on RHEL 8 and RHEL 9 and the permission was not changed on existing repositories.

# umask
0022
# mkdir /usr/local/lib64/perl5 /usr/local/share/perl5
# ls -ld /usr/local/lib64/perl5 /usr/local/share/perl5
drwxr-xr-x. 2 root root 6 Mar 10 02:49 /usr/local/lib64/perl5
drwxr-xr-x. 2 root root 6 Mar 10 02:49 /usr/local/share/perl5
# umask 0077
# cpan -a  
Loading internal null logger. Install Log::Log4perl for logging messages

CPAN.pm requires configuration, but most of it can be done automatically.
If you answer 'no' below, you will enter an interactive dialog for each
configuration option instead.

Would you like to configure as much as possible automatically? [yes] 
CPAN: HTTP::Tiny loaded ok (v0.074)

[...]

# ls -ld /usr/local/lib64/perl5 /usr/local/share/perl5
drwxr-xr-x. 2 root root 6 Mar 10 02:49 /usr/local/lib64/perl5
drwxr-xr-x. 2 root root 6 Mar 10 02:49 /usr/local/share/perl5

The same result was for cpan -l.

There is another vendor who ran into this same issue where their product tried to invoke "cpan -l" cpan also changed the permissions. I suspect these users also had never run cpan before and when their product did, it made the modifications. https://success.qualys.com/support/s/article/000007702

I think the expected behavior here is for cpan to not change the permissions to any existing directories regardless if it is the first time being run or not but this is what happens on RHEL and might happen on other distro's. I encourage you to test this and confirm the unexpected behavior.