run docker container as non-root

Current Behavior

The current Docker image creates and uses user sqld and root, which works fine for standard Docker deployments. However, when running in Kubernetes with security constraints like readOnlyRootFilesystem: true, we encounter permission issues because the container attempts to change ownership of files in the mounted volumes.

Proposal

Consider using a higher UID/GID in the range of 10000-65535 (specifically 10001 is commonly used in Kubernetes environments). This range is:

• Less likely to conflict with host system users
• Aligns with Kubernetes security best practices
• Follows the practices of many official container images designed for Kubernetes

Use Case

In Kubernetes environments, especially those following security best practices, it's common to:

• Run containers with readOnlyRootFilesystem: true
• Use fsGroup for volume ownership rather than in-container chown
• Avoid privileged containers or init containers when possible

Making the container work well in these environments would benefit users running in hardened Kubernetes clusters.

Start by locating the Docker image definition and tracing how the sqld and root users are created, selected, and used for mounted-volume ownership. Check the image under read-only-root-filesystem and Kubernetes fsGroup constraints; done means it runs with a high non-root UID/GID without requiring in-container chown.