Third-party applications that use their own installation systems may have built-in assumptions about the system default umask.
As a practical example, after updating an Oracle 10 database on a system that had the umask set to 077, the applications on the same system failed to access the database... because the libraries essential to the database clients, and the directories the libraries were located in, were now protected so that only the oracle
user could access them, which was obviously not how things were supposed to work.
It turns out the Oracle updater process did not specifically take care that the permissions of the client libraries would allow other users to use them, but instead relied on the assumption that the files added by the updater would be created with umask 022 and so be usable by default. After a few judicious chmod -R a+rX
commands for the appropriate directories, all was well again.
Granted, this could have been avoided by treating the oracle
account as a special system account with standard umask 022, and restricting the umask 077 to actually login-able user accounts only... but I think this is a good example of how blanket "hardening" decisions can have unforeseen side effects.
.rpm
and .deb
packages carry explicit permission information for any files they contain, so they don't generally have the risk of errors of this type.