Cannot Generate CA as .ocm dir is too restrictive.

[reedjosh]

I finally created my own load balancer service outside of the helm chart to get around the extra 'n' issue, but now, I'm seeing that the .ocm dir is locked down enough that the pod cannot generate its own cert.

failed to generate root-ca CA certificate: mkdir /.ocm/cert: permission denied

I'll probably find a workaround for now, but please look into the permissions for this directory.

Thanks!

[reedjosh]

[reedjosh]

Okay, forked your repo, and changed a few chart things. Primarily the security context, but I've gotten a bit further 🙌 .

I think I'm starting to understand the /.ocm dir issue. Basically if you runAsNonRoot, but don't set the security context, then you'll have 0 access to the diretory.

Using the security context field the dir can be made so that it's owned by your user and your user's group.

Of course then you'll get the too permissive warning.

I think from there modifying the perms to be only accessed by your user is practically the only solution.

Init container, or just as part of the bin startup process.

[clyang82]

/assign @ycyaoxdu

[clyang82]

Hi @reedjosh , what platform are you using? we know the folder permission can be a potential issue #81. Definitely, we need to look into the permissions for this directory.

[reedjosh]

I'm using EKS.

But really this may be an issue whenever a PVC is used, the pod user is nonRoot, and security context is not set on the deployment.

If not set, the PVC comes in owned by root.

If set, then it can be made owned by the running user.

Either way I'm not sure if the perms can be set to 700 to begin with or not.

When I changed the security context it came in as full perms to all 777.

[clyang82]

Yes. it seems we cannot change the permission by using securityContext. We can have an initContainer to change the permission, but it requires runasroot. it may have problem in some environments.