Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Confluence docker container changes permission of own directory Edited

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

 

4 answers

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

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.)

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.)

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.

0 votes
Dave Chevell Atlassian Team Sep 04, 2019

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

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

0 votes
Dave Chevell Atlassian Team Nov 21, 2019

@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.

Hi Dave,

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

 

Br
Markus

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. 

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Posted in Confluence

What do you think is the most *delightful* Confluence feature? Comment for a prize!

- 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...

402 views 23 8
Join discussion

Community Events

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

Events near you