Change JIRA attachment folder path

Posted by DH on Wednesday, 5 August 2015

As of Atlassian, setting a custom path for attachments in Jira is considered “a potential security risk”, and thus deprecated. This is not about arguing on whether admins without a sane idea of security concepts should be considered in on-premises application concepts at all (which I do not think, as you may guess). Instead, I will assume that you, like me, half-way know what you are doing and thus explain my workaround for this, as I figure, severe issue. (Honestly, just have virtualization clusters and SAN in mind. Please go figure, Atlassian.) But ok, let’s see the good intention and do it on our own.

Problem

While they suggest using a symlink for the attachment folder path (data/attachments within the Jira application root path, /var/atlassian/application-data/jira/data/attachments in our case), this fails if you simply move the folder elsewhere and then symlink or mount it. From my understanding, there are some integrity checks happening inside which seem to include file and folder attributes. Soon after changing the folder structure, Jira will refuse to work and (in our case) throw a tomcat error page indicating some lock and other issues.

Solution

To bypass the said integrity checks, a certain process is required, while their above suggestion is basically correct (and also a bit weird, but more on that below).

  1. Go to Administration > System > Attachments > Edit settings.
  2. Disable all three options (allow attachments, zip and thumbnails).
  3. Save the settings.
  4. Now move your folders (I had zipped the existing attachments prior to the operation), and make sure, the symlinked (or mounted, which one is irrelevant as long as the folder permissions remain the same as before) folder is empty (important!).
  5. Open the attachment settings again.
  6. Restore the said switches to their previous states (enabled).
  7. Save the settings.
  8. This should end up with attachments being enabled again and set to the “default path”, which is now somewhere else. A successful operation will close the settings overlay popup and take you back to the main view. If the popup layer stays open, and/or you do not clearly see a change, something went wrong.
  9. If you made it and attachments work again, you can relaxedly transfer back all the stuff you previously moved aside (still mind permissions; tar did just the perfect job here).

Go figure, because

I do not get the actual point. This kind of validation hardly helps anything, except for annoying “on premises” users. But I may miss something. However, if I were up for no good, from this point on I could still do any evil thing of my choice and also from anywhere outside that system. And all that is to keep me from doing it is a blocking level with annoyance potential? This looks more like activism than like a focused solution (for exactly which issue, by the way?).

To make myself clear, I do not say they should “try even harder”. Au contraire. Stop nannying, would you please. Do place a clear, deep-red warning “you are doing something here” or whatever, and/or link to the issue or security report behind it, but please. Let admins do what admins do. Just in case some Atlassianist reads along (I like your work in almost any other way).

Warnung

Of course, there is some risk. In the end, where isn’t. The above suggestions assume that you have a clear understanding of remote file systems, of how to secure access to them, how to probably protect the actual data traffic, and how to set up proper NFS/CIFS mounts or symlinked folders on iSCSI targets. If you don’t, using hosted services may still be the better decision.

Hope I could be helpful, additions are welcome.