"Permission Denied" error when I build my stack via AWS Cloudformation

giridhar 2019-06-06 15:59:05 UTC #1

Keywords: MariaDB - AWS - Technical issue - Permissions
Description:
I'm getting "Permission Denied" error when I build my stack via AWS Cloudformation.

I believe that's because of the user 1001. I don't want to change the volume permission manually.

I have set the docker user property to root. But still having that issue. Is there a way I can run the container as root instead of 1001?

Thanks

jota 2019-06-07 10:54:41 UTC #2

Hi @giridhar,

Could you please let us know more information about the Bitnami solution you are using (if SingleVM or MultiTier) and the process you are following to deploy it? It'd be very useful if you also share a screenshot with the error message you obtain in the AWS portal.

Thanks

giridhar 2019-06-07 13:02:23 UTC #3

I was using bitnami wordpress and mariadb images.

I moved to the official mariadb and wordpress image since I can't able to progress.

I would love to use your image. I hope you can provide a solution.

I use aws cloudformation to build my stack.

Here is my Task definition template. https://gist.github.com/Viruthagiri/778b88ba685f905ddf064fce17f4a10b

I actually tried with

User: root

Also tried with

Privileged: true

But had the same permission issues.

An AWS support guy spent more than 4 hours in trying to fix the problem. But he couldn't.

This is the error we had.

https://www.dropbox.com/s/5ei12xginai4em2/Screenshot%202019-06-06%2017.06.35.png?dl=0

We even tried by running as root.

https://www.dropbox.com/s/so2njek1u737rmx/Screenshot%202019-06-06%2017.05.47.png?dl=0

We also got error like this.

Can't change dir to '/bitnami/mariadb/data/' (Errcode: 13 "Permission denied")

Do let me know if you need more info.

Thanks

jsalmeron 2019-06-11 00:25:10 UTC #4

Hi,

The cause of the issue is because our container is non-root. Therefore, if the mounted volumes do not have the proper permissions, the container will fail. In Kubernetes this is solved using the securityContext option. In AWS Cloudformation, if there is no option for setting the ownership of the volume, what you could do is launch a root container (such as bitnami/minideb) with the MariaDBVolume mounted, and execute chmod og+rwx in the mounted folder. This way, the mariadb container will mount a volume with the correct permissions.

Hope it helps.

Best regards,

Javier J. Salmerón

Was my answer helpful? Click on

giridhar 2019-06-11 12:52:06 UTC #5

If i'm not wrong chmod og+rwx is giving permission to the world to read, write and execute. Isn't that a permission issue? You guys removed root user to make it secure right?

jsalmeron 2019-06-11 21:04:55 UTC #6

Yes. Using non-root containers is a best security practice, and it is an essential requirement for running our containers in Openshift. As we do not know the ownership of the volume, that's why I'm telling you to set these open permissions in the first place.

Best regards,

Javier J. Salmerón

Was my answer helpful? Click on

giridhar 2019-06-12 10:59:13 UTC #7

I never seen such requirement in any of the github readme file. Or am I missing something?

https://github.com/bitnami/bitnami-docker-mariadb

If I knew your container won't work in AWS i would never have spent a week in trying to make it work.

jsalmeron 2019-06-12 18:41:22 UTC #8

Hi,

In our Readme you find a link to this page https://docs.bitnami.com/containers/how-to/work-with-non-root-containers/. It seems to me that the Volume setting from AWS CloudFormation is not 100% compatible with non-root containers unless you add an extra one that changes the permissions.

Best regards,

Javier J. Salmerón

Was my answer helpful? Click on

giridhar 2019-06-13 12:11:06 UTC #9

Hello Javier,

We already know the issue was related to volume permissions. See my original post. I already figured that by interacting with AWS support.

My concern here is that your containers are not working even if we set "root" value to the docker-compose "User" variable.

AWS is the world's largest cloud provider. I'm surprised you guys ignore them just like they don't matter.

Why not make the user 1001 as a modifiable docker variable?

jsalmeron 2019-06-17 16:55:13 UTC #10

Hi,

Thanks to your report, I found that the container has issues when running as root. I am preparing a PR to have it fixed so you can use the container as root in AWS. Stay tuned!