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.

Work on the Komodo-CFML front

Things on the Komodo-CFML front have been pretty quiet here of late, but that’s not because nothing has been going on. Several months ago, as I wrestled with some odd behavior I was seeing with the extension under then-new Komodo v9, I came to the conclusion that there were a couple of fundamental problems with the approach I had taken in tokenizing CFML (used in Komodo to provide syntax colorizing). Furthermore, that approach appeared to make it nearly impossible to do much in terms of any sort of code intelligence-type help.

So… I started over. Completely. Threw everything out and started from the ground up, building an entirely new version of the extension. (Actually, I started over three times, trying to make sure I had a better approach.) At one point, I got stuck waiting for resolution of a bug relating to how Komodo creates the skeletons of extensions.

At this point, I am very close to having this completely-rebuilt version ready to release (probably as a v0.2.5). I’ve tried to make sure it provides everything the current v0.2.4 does in terms of syntax highlighting, but it also has a couple additions:

  • completely reworked DTDs for CFML + HTML5 (for both CFML v10 and v11), with content models that provide better and more consistent access to CFML tag and attribute completion
  • CFML language keyword, scope, and function name completion (this is what I started working on and ended up heading down the rabbit-hole that led me to scrap everything and start over)
  • macros for CFML help for the word under the current caret position and for CFML comment/uncomment region that work in a manner consistent with Komodo’s built-in comment/uncomment region (more on this at some later date)

So… I’m close. Close enough that I have been using this new (still evolving) version for my daily development work for several weeks. I’m waiting for one additional Komodo bug to be resolved (hoping it will be included in Komodo v9.3, which is in the nightly-build prerelease stage at this point). I will post something here when I release it, as well as making it available through the Komodo packages repository.