Umasking Security Theater

Umasking Security Theater

Wasted several hours debugging a questionable environment setting

TL;DR

I recently spent several hours debugging an issue that was ultimately caused by an unnecessarily restrictive system umask setting. The current umask of 0027 causes newly created or rewritten files to lose world-read permissions, which can result in difficult-to-diagnose failures such as JavaScript files returning HTTP 403 errors. In a development environment, the operational overhead and lost productivity caused by this setting appear to outweigh its benefits. I recommend changing the default umask from 0027 to 0022.

Details

While investigating intermittent JavaScript loading failures, I discovered that some files were being created with the following permissions:

$ ll /path/to/file.js

-rw-r----- 1 user group 960591 Apr 10 18:42 /path/to/file.js

Because the file lacks the o+r permission, the web server is unable to read it, resulting in a 403 Forbidden response when the browser attempts to load the JavaScript.

Further investigation revealed that the umask is globally set to 027 in both /etc/profile and /etc/bashrc:

if [ $UID -gt 199 ] && [ "`/usr/bin/id -gn`" = "`/usr/bin/id -un`" ]; then

    umask 027

else

    umask 027

fi

This means that any newly created or replaced file will have permissions derived from that restrictive umask.

Originally, I believed this problem only occurred when Git rewrote files during operations such as git pull. However, it turns out that editors such as VS Code can trigger the same issue. VS Code often saves files by creating a temporary file and then replacing the original file. When that happens, the new file inherits permissions based on the current umask, resulting in permissions such as:

-rw-r-----

As a result:

1. A JavaScript file is edited and rewritten.
2. The restrictive umask removes world-read access.
3. The web server can no longer read the file.
4. Requests for that JavaScript file return 403 Forbidden.
5. Application functionality breaks in ways that are not immediately obvious.

This creates exactly the kind of silent or difficult-to-diagnose failure that can consume hours of debugging time unless someone already knows to check file permissions.

The existing fixFilesRights.pl script appears to exist solely to compensate for this behavior. While it can repair permissions after the fact, it does not help during normal development and testing. A developer may repeatedly edit, test, and troubleshoot code long before any Git hook or permissions-fix script is executed. By that point, the time has already been lost.

Additional Observations

The umask configuration appears to deviate from the more common RHEL/Amazon Linux defaults, which typically result in less restrictive permissions for normal users. In this environment, both branches of the conditional explicitly set umask 027, enforcing the same restrictive behavior in all cases.

While such a setting may be appropriate in environments that require strict data isolation, it introduces significant friction in a development environment where web content must be readable by the web server.

Additionally, the intended security benefit is somewhat undermined by the fact that users can override the global umask in their own shell startup files by setting:

umask 022

Because our accounts are shared, changing the umask for a given account affects multiple users. As a temporary workaround, I have changed the setting for vs.srvc.acc4@ause1d1ovfa101 (Delusion), but this is not an ideal long-term solution.

Recommendation

I recommend changing the default umask from 0027 to 0022 in development environments. Doing so would:

• Prevent static web assets from unintentionally becoming unreadable.
• Eliminate a common source of 403 errors.
• Remove the need for permission-repair workarounds such as fixFilesRights.pl.
• Reduce time spent debugging issues unrelated to application logic.
• Provide more predictable behavior across Git operations, VS Code saves, and other development tools.

Given the amount of confusion and lost productivity this setting causes, a default umask of 0022 appears to be the more practical choice for development systems.

The scope of this issue appears to be broader than initially understood. It is not limited to pulling from Git; it also affects editing files through VS Code and potentially other development tools.

Given that our development environments are already protected by the corporate VPN, I believe the concern around users being able to read JavaScript source code—particularly when those users are running the web server itself and therefore require read access—may be overstated. Since we routinely reverse these permission changes and have even automated the process, the current umask configuration feels more like a procedural hurdle than a meaningful security control.

Because this impacts all of us, and I am not aware of anyone who would benefit from these restrictions in our shared development environment, the simplest solution would be to add umask 0022 to the ~/.bashrc of each shared development account. This would eliminate the recurring permission issues while preserving the existing network-level security controls already in place.