WHY did default linux file permissions for ${MATLAB_R​OOT}/toolb​ox/local/p​athdef.m change in R2022?

We have a multiuser linux server install of R2022b and a user recently modified ${MATLAB_ROOT}/toolbox/local/pathdef.m which affected all users. (Easy to fix problems created by someone, but it was unexpected they could change something that deep into the system directory.)

In R2022b and another instance of R2022a I have access to, this file (with $MATLAB_ROOT=/usr/local/MATLAB/R2022b) is owned by root/admin and almost everything is read or read/execute. This file,however, is RW for group and other. In other words, it is modifiable by all users on the system.

In R2021a that we still have installed, this file is read only. Did this slip through the cracks, or was there an intentional change for this?

(I can't think of any good reason for letting any system user alter the pathdef.m systemwide, so i'm curious about WHY.)

classpath.m in the same directory is also read/write across the board.

[Daniel]

Is there a possibility that someone manually changed the permissions on that file after installation? My first suggestion would be to reinstall in a sandbox and see if the permissions make sense on a clean install, if you haven't done so already.

[jessupj]

there is almost no possibility that anyone manually changed permissions other than myself, and the system logs/audit show no changes to the file permissions.

I just installed R2022b and R2023a in sandboxes.

R2022b does in fact seem to default to system-wide read/write of pathdef.m which is run automatically at login for all users. attached: screenshot of the directory for a clean install of R2022b that I downloaded from TMW a few minutes ago.

In the R2023a instance, this file read only like it's been for as long as i can remember.

[Daniel]

In that case, your best bet for a fast solution is probably going to be a manual permissions fix (if you haven't already done that). If you would like, it might be useful to report a bug so the R2022b and R2022a Linux installers can be updated, even though the issue doesn't exist in the latest release.

[jessupj]

Thanks, Daniel. I followed your suggestion and submitted a bug report. I'd be very surprised that nobody had mentioned this before, which is why I'd expected there to be some reason for it. In the meantime, as a public service, i'd suggest to anyone reading this running a '22 release to set this file to read only if the installer set it with open write access.