Confluence docker container changes permission of own directory

[Markus Sadler]

Hi!

I am trying to get the official Confluence Docker image from Dockerhub to run on a Openshift Cluster.The pods have the /var/atlassian/application-data/confluence directory mapped to a persistent volume, which is mounted via NFS on another server. 

At startup of the confluence-server pod the directory permissions of the mounted NFS directory get automatically changed to 700 (read/write/execute only for owner and root). Even if I set it before to read/write/execute for everyone it gets automatically changed to 700 at startup. 

As a result i get the errorpage that confluence needs read/write/execute permissions on the directory.

Anyone knows why the permissions change automatically and how to prevent this?
I don't want to have container run as root because of security concerns....

Kind regards

Markus

[Dave Chevell]

@Markus Sadler just for reference, our Jira image now supports passing `SET_PERMISSIONS=false` as an environment variable and it will skip setting permissions on startup. It also handles being run as a non-root user, and will simply skip bootstrapping any config files which are locked to root for security reasons (e.g. server.xml) - in those cases you can inject your own config files in a number of other ways, whether mounting them directly as files or building your own images from ours.

[Markus Sadler]

Hi Dave,

Thank you! This is exactly what i need! Will this feature be also implemented in the Confluence image?

Br
Markus

[Dave Chevell]

That's the plan - for Confluence and for Bitbucket! (And, whether or not it matters, my unofficial `dchevell/crowd` image too)

There are some in-flight pull requests for these, so if you like I'll update you when Confluence is updated with this flag.

Edit: This is now live for `atlassian/confluence-server`! As always just re-pull whatever tag you're using, they've all been updated. 

[Dave Chevell]

Hey @Markus Sadler ,

When you start the container for one of our images, although the entrypoint process runs as root in order to perform some pre-start configuration/setup, it runs the actual application as a non-root user (e.g. "confluence" with uid/gid 2002).

I just want to confirm, is that still a concern for you, given the application is not run as root? Let me know.

Cheers,

Dave

[Markus Sadler]

Hi, thanks for your Reply!

Yes, the issue is still a concern for me. I forbid the container from changing the filesystem permissions on the persistant storage host and now it can not delete it's own permissions but i don't think that this is a final solution….

Cheers,
Markus

[pkware]

Ran into the same issue with an upgrade. Turns out Atlassian has a script that changes the owner of confluence directory but not the owner of any file underneath that directory.

And that was the key for us. We had that directory persisted outside of the container. What I had to do was connect to the container while running and change the ownership recursively for the entire tree. After I did that I restarted the container and everything worked fine.

[pkware]

I should probably note at this point that I tried to report this as a bug to Atlassian, but they don't apparently accept bug reports from folks with our particular license, so while this is their fault, they won't let me tell them what they did wrong nor how it can very easily be fixed. (Just add -R to the chown they do on that directory during  container initialization.)

Sigh.

If you need to do it, the form of the command is:

docker exec -ti containername sh -c 'command'

 You know what name you gave the container, and the command will probably be:

chown -R confluence:confluence /var/atlassian/application-data/confluence

(or at least that's what I needed, YYMV.)

[Dave Chevell]

Hey @pkware , my apologies for your frustration - I'm one of the folks working on these images and I'd like to take a closer look at this.

I'm playing with the idea of tweaking a few permissions and some of the entrypoint logic to see what would be required to make running the container as a non-root user on startup work out of the box. 

By the way, when executing a command in a running container with docker exec, the `-it` (or `-ti`) flag is only needed if you need to run the command interactively. For example, a command that asks for further input, running a bash interpreter you want to subsequently enter further commands into, etc. For non-interactive commands you can omit it entirely:

docker exec confluence whoami

Just thought you would be interested to know!

[Markus Sadler]

Yes, this is also a solution for the Problem but i try the get Confluence run on a Open Shift cluster, where everytime when i Change some configs or pull a new Image the container gets killed and a new one is created. Changing the permissions inside would simply a lot of constant manual work which i don't want do do......

[pkware]

Sorry, been awhile since I was here. Yes, @Dave Chevell I know that's only necessary for interactive commands, but I still do it all the time, just out of habit.

Running as non-root would be a great idea. Means an attacker would have to add a privilege escalation to the exploit, so lets the distro add its own strength to confluence's when attacked.

[Markus Sadler]

I fixed it temporarily by not allowing the daemon user to change the directory permissions:

chown root <confluence-home> 

 Now at server startup the file permissions can not be changed and i don't run into the error that confluence takes away it's own rights to write to the directory:

But in my opinion this is a very dirty fix.......