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.

Background

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…

OS X Yosemite: First thoughts

I upgraded my MBP (a 15-inch, early 2011 model) to OS X Yosemite on Friday morning, and at this point I am closed to being finished with getting software installed, etc. I typically move between versions of OS X with a clean install and then re-install software and restore files (as needed). It’s not necessarily an approach that would work well for everyone, but it works for me and helps ensure I have a reasonable clean system.

My first thoughts, in no particular order:

  • Helvetica Neue as the primary UI font is going to take some getting used to. My MBP is a couple years old, and is not a Retina device; that has a big impact on how it renders. I particularly notice the difference in the menu bar and in context menus. It simply does not render as clearly and legibly as the font OS X has historically used there.
  • The flat UI will also take some getting used to, but I think I like it, in general, for window decorations, UI controls, icons, etc.
  • I am not crazy about the shift to brighter colors for UI elements and icons. I would characterize many of them as close to garish. I tend to like understated UIs (the theme of my blog will attest to that) and while the flat aspects of the UI head in that direction, the colors most certainly do not. The blue used for UI elements, folder icons, etc., is particularly bad in this regard. The second UI tweak I made was the shift to graphite for basic UI appearance (which unfortunately does nothing for the blue folder icons); the first was to shift the dock to the right side of the display and to have it auto-hide to slide the mass of bright colors out of sight. I hardly ever use the dock (thank you, apps like QuickSilver and Alfred!), so this is something I would do anyway, but I don’t miss the explosion of bright colors from the dock.
  • Transparency and effects: I haven’t decided about these, but in general they feel like a bit much to me. What benefit, for example, is there to having the blue of several selected files in a Finder pane bleed through the context menu when I right-click on them? There are places where I like a bit of window transparency but some of the transparency implemented here feels gratuitous.

My overall general impression: a mixed bag. This is the first OS X version I’ve installed (going back to when I started with OS X Leopard) where I have not had an overwhelmingly positive reaction to the UI evolution.

I’ll follow up a bit after I’ve been on Yosemite for a couple weeks with additional impressions. I’m curious to see how/if these impressions evolve with the passage to time and usage. The other aspect of this is that the system I updated is my own laptop; I have two other MBP’s I use for work and I don’t have any near-term plans to update them… I will be switching between 10.10 and 10.9 on a daily basis, which will likely bring the differences into sharp contrast.

Setting up a HyperSQL Database Server

I’m in the process of rebuilding one of my development boxes at the moment, and when I needed a SQL database engine this weekend to support a bit of quick prototyping, I decided I would take a shot at setting up a HyperSQL database server. This is something I’ve been meaning to look into for other reasons for a while: HyperSQL is small, fast, flexible, provides good SQL coverage (more complete, for instance than Apache Derby), and has the ability to tune its behavior to more closely mirror other SQL engines.

Here is a quick recipe for getting a basic server up and running. This should work equally well on both Mac OS X and Linux (I have used this basic recipe on both platforms).

My system already has a Java 7 JRE/JDK installed with the java command available in the shell’s PATH, which is really the only prerequisite. For the sake of simplicity, I install HyperSQL in /opt/hsqldb and I keep my database-related files in ~/hsqldb-catalogs/. Commands entered at the shell prompt are shown below starting with $, while commands entered in the HyperSQL CLI are shown below starting with >. Note that some of these commands may appear wrapped below; they should each be entered on a single line when used.

  1. Download the latest version of HyperSQL (version 2.3.1, as of this writing) from hsqldb.org.
  2. Unzip the downloaded file (assumed to be in ~/Downloads/):
    $ cd ~/Downloads
    $ unzip hsqldb-2.3.1.zip
    $ sudo mv ./hsqldb-2.3.1/hsqldb /opt
    $ rmdir hsqldb-2.3.1
  3. Create the folder where the server will store its database files:
    $ mkdir ~/hsqldb-catalogs
  4. Create the properties file that provides basic information for the server, including our test database. Save this file as ~/hsqldb-catalogs/server.properties:
    # File: server.properties
    # =====
    # HSQLDB configuration file
    # Databases:
    server.database.0=file:test/test
    server.dbname.0=testdb
    # =====
    # Other configuration:
    # Port
    server.port=9001
    # Show stuff on the console (change this to true for production):
    server.silent=false
    # Don't show JDBC trace messages on the console:
    server.trace=false
    server.no_system_exit=false
    # Do not allow remote connections to create a database:
    server.remote_open=false
    # =====
  5. Create the configuration file for the CLI HyperSQL tool, describing two different connections to our test database: one as the default system administrative user “SA” and one as a normal administrative user “RON” which we will create in a few minutes. Save this tool as ~/sqltool.rc:
    # File: ~/sqltool.rc
    # =====
    # Connect to testdb on localhost as SA (no password initially):
    urlid localhost-sa
    url jdbc:hsqldb:hsql://localhost/testdb
    username SA
    password
    # Connect to testdb on localhost as RON:
    urlid localhost-ron
    url jdbc:hsqldb:hsql://localhost/testdb
    username RON
    password strong-random-password
    # =====
  6. Start the server. This will create our test database using the following commands in a terminal window:
    $ cd ~/hsqldb-catalogs
    $ sudo java -cp /opt/hsqldb/lib/hsqldb.jar org.hsqldb.server.Server --props ./server.properties
  7. Open a second terminal window and start the HyperSQL CLI “sqltool”, connecting to our test database as user “SA”:
    $ java -jar /opt/hsqldb/lib/sqltool.jar localhost-sa
  8. As a general rule, I don’t like signing in using the system administrator account, so the first thing I typically do is create an administrative user account for my use:
    > create user RON password 'strong-random-password';
    > grant DBA to RON;
    > \q
  9. Make sure you have your “strong-random-password” recorded correctly in ~/sqltool.rc, and restart the HyperSQL CLI:
    $ java -jar /opt/hsqldb/lib/sqltool.jar localhost-ron

You’re done. You have a fully-functional database server, providing a single database called “testdb” for your use.

If you want to play with sample data, consider the following (while connected as either “SA” or your administrative account):
> create schema sampledata authorization DBA;
> set schema sampledata;
> \i /opt/hsqldb/sample/sampledata.sql

When you’re ready to shut down the server, you can do it while connected to the server as a user with DBA role:
> shutdown;

Alternatively, you can shut down the server from the command-line:
$ java -jar /opt/hsqldb/lib/sqltool.jar --sql 'shutdown;' localhost-ron

Some final thoughts:

  1. Read the docs: the user guide and the utilities guide for HyperSQL are good, and provide thorough coverage of what HyperSQL is capable of (which appears to be quite a bit) and how to use it, including connecting via JDBC.
  2. You almost certainly want to set a password for the default “SA” user, and remember to update your ~/sqltool.rc file when you do.
  3. Protect ~/sqltool.rc — obviously this file, with information about catalogs, users, and passwords needs to be protected.