Confluence docker container changes permission of own directory
Asked by Markus Sadler:

Hi!

I am trying to get the official Confluence Docker image [from Dockerhub](https://hub.docker.com/r/atlassian/confluence-server)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


Answers:
author: Dave Chevell
body: [@Markus Sadler](/t5/user/viewprofilepage/user-id/1373586) 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.

comments: author: Markus Sadler
body: Hi Dave,

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

Br  
Markus


author: Dave Chevell
body: 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.


author: Dave Chevell
body: Hey [@Markus Sadler](/t5/user/viewprofilepage/user-id/1373586) ,

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

comments: author: Markus Sadler
body: 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


author: pkware
body: 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.

comments: author: pkware
body: 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.)


author: Dave Chevell
body: Hey [@pkware](/t5/user/viewprofilepage/user-id/393191) , 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!


author: Markus Sadler
body: 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......


author: pkware
body: Sorry, been awhile since I was here. Yes, [@Dave Chevell](/t5/user/viewprofilepage/user-id/792201) 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.


author: Markus Sadler
body: 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:

![image.png](https://community.atlassian.com/t5/image/serverpage/image-id/62890iAA1E79FAAC6AA8D6/image-size/large?v=v2&px=999 "image.png")

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


Tags: confluence-server

docker

server