File/Directory Permissions Oddities After Applying Adobe ColdFusion 11 Hotfix(es)

I recently ran into an issue applying Adobe ColdFusion 11 Hotfix 7 (released 2015-11-17) and decided it was worth documenting for my own retention and on the off-chance this might help someone else who bumps into this in the future. The bottom line is that at least the installers for ACF11 Hotfixes 6 and 7 fiddle with file and folder permissions in a way that may cause problems with applying subsequent hotfixes and that seems dodgy. I emphasize “at least” because those are the only two ACF11 hotfix installers I’ve applied (as we just recently migrated from ACF10 to ACF11) and it is possible this behavior has been present in previous ACF11 hotfix installers. This behavior does not seem to be present in ACF10 hotfix installers to date. Further, I emphasize that this might cause problems because it depends on how your ACF11 is deployed and how you apply hotfixes to that deployment.


I develop almost exclusively on Mac OS X, but the issue I bumped into could also be present on Linux installations. (It seems less likely to me that it will be present for Windows installations.) On my development systems, I deploy all of my application servers via WAR files as Tomcat instances on a stock Tomcat installation in a folder structure within my own user account’s home directory. My user account owns all of the files and folders within that directory structure. Further, I run, stop, and start the Tomcat instances as myself (e.g., they run as my user account and thus have no elevated privileges). None of these Tomcat instances start or stop unless I manually start or stop them, so they are only running when I need them. This approach makes it very straightforward for me to have multiple application servers (or versions of a given application server) deployed and even running concurrently if I manage ports correctly. This has been a real boon in migrating between versions of ACF, testing Railo and Lucee next to ACF, testing hotfixes… and figuring out what was going on with this particular issue. My deployment folder structure looks like this:

~/opt/t7i (all Tomcat 7 instances)
   ./cf10/ (Adobe ColdFusion 10)
   ./cf11/ (Adobe ColdFusion 11)
   ./l4/ (Lucee 4.x)
   ./l5/ (Lucee 5)
   ./railo/ (Old Railo deployment)

~/opt/t8i/ (all Tomcat 8 instances)
   ./l4/ (Lucee 4.x)

When Adobe releases ColdFusion hotfixes, I download them (typically from within the ColdFusion administrator UI), stop the relevant Tomcat instance, and then apply the hotfix from the command line, per the following example:

$ cd ~/opt/t7i/cf11/webapps/ROOT/WEB-INF/cfusion/hf-updates
$ java -jar ./hotfix-007.jar -i GUI

The Symptoms

The issue showed up when I first tried to apply ACF11 Hotfix 7 on the first of my development systems: installation of the hotfix failed with a fatal error, indicating in the installation log that it could not move files into folder ~/opt/t7i/cf11/webapps/ROOT/WEB-INF/cfusion/lib. That seemed odd, as I had previously used this same approach with multiple ACF10 hotfixes and with ACF11 Hotfix 6 on each of my development systems (including this one).

Given that my user account owns all of the files and folders where the Tomcat instance for ACF11 is installed, and that I was applying the hotfix as myself, why would working with those files and folders fail?

I reached out to the ACF team via a comment in the blog post announcing the hotfix and Nimit Sharma (@nimsharm) of the ACF team followed up with me shortly thereafter. He suggested trying to apply the hotfix as “root” (i.e., with elevated privileges) to see if that resolved the problem. After expressing my reluctance (there are reasons behind why I install and run these application servers in the manner I do), I set aside copies of the instance, and used sudo to apply the hotfix. It applied successfully.

Hmmm… what’s going on here? Clearly something related to permissions…

The Issue

After a couple run-throughs of installing ACF11 and applying first Hotfix 6 and then Hotfix 7 while keeping an eye on file ownership and permissions, I’ve determined that at least the installers for these two hotfixes fiddle with file and folder permissions within the ACF deployment in ways that do not make sense to me:

  1. The Hotfix 6 installer changes group permissions on the following files and folders from r-x to rwx:
    • ~/opt/t7i/cf11/webapps/ROOT
    • ~/opt/t7i/cf11/webapps/ROOT/WEB-INF/cfusion/hf-updates/hf-11-00006/uninstall/.com.zerog.registry.xml
    • ~/opt/t7i/cf11/webapps/ROOT/WEB-INF/cfusion/hf-updates/updates.xml
  2. The Hotfix 6 installer changes user folder permissions on the following folders from rwx to r-x:
    • ~/opt/t7i/cf11/webapps/ROOT/WEB-INF/cfusion
    • ~/opt/t7i/cf11/webapps/ROOT/WEB-INF/cfusion/lib
    • ~/opt/t7i/cf11/webapps/ROOT/WEB-INF/cfusion/lib/updates

It is the removal of user-write permissions by the Hotfix 6 installer that causes installation of Hotfix 7 to fail, but adding group-write permissions on the folders is pretty suspect from a security perspective.

I’ve posed the question to Nimit of the Adobe team as to why the installers do this, but have not received a response from him so far. I can’t come up with any reason that the installer should be fiddling with group permissions on those folders (but particularly in opening up write permissions on these folders). There may be a good reason that user-write permission is removed from the other folders but it causes problems with applying subsequent hotfixes. The “Adobe ColdFusion 11 Lockdown Guide” alludes to this  (see p. 45) in discussing ownership and permissions on Linux systems and the potential for these causing problems  if not configured in a way that’s consistent with how ColdFusion is run and hotfixes are applied.

By walking through installing ACF11 (which left the folders as expected), applying Hotfix 6 (which left the needed folders unwriteable), and then applying Hotfix 7 (which failed), I’ve determined that this was not a problem with just Hotfix 6. It is a problem with both Hotfix 6 and Hotfix 7: Hotfix 7 behaves the same as Hotfix 6 in adding group-write permission to the same folders, and removes user-write permission from the same/corresponding folders.

The Resolution

Resolving the problem after applying each of the hotfixes is straightforward:

$ cd ~/opt/t7i/cf11/webapps
$ find . -perm +g+w -exec chmod -v g-w {} \;
$ find . -not -perm +u+w -exec chmod -v u+w {} \;

The second command finds any files or folders that are group-writeable and removes group-write permission. The third command finds any files or folders that are not user-writeable and adds user-write permission.

Wrapping Up

At this point, I’ve figured out why Hotfix 7 failed to install and figured out how to revert file/folder ownership and permissions to a state that makes sense. Part of my approach to installing and updating ACF my various systems now includes an additional step to find and fix any files/folders whose user/group permissions are no longer consistent.

My questions, however, remain:

  1. Why is the hotfix installer adding group-write permissions to several files/folders as part of the applying the hotfix?
  2. Why is the hotfix installer removing user-write permissions from several key folders within the ColdFusion folder structure as part of applying the hotfix, particularly when doing so leaves the ColdFusion installation in a state where future hotfixes will fail to install?

I will update this when Nimit from the Adobe team follows up with me.

Update 2016-05-14: No responses received (yet?) from anyone at Adobe, and based on my preliminary investigation with the installer for CF11 Hotfix 8 (release earlier this week), its installer behaves identically. My two questions above remain unanswered…