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....
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.......
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.
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.)
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.)
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!
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......
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.
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.
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….
@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.
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.
- Create your own custom emoji 🔥 - "Shake for Feedback" on mobile 📱 - An endless supply of GIFs via GIPHY 🤩 Is there anything quite as nice as a pleasant surprise? Comment below with what...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events