Enable running as "rootless" on kubernetes (problem with alteration-scripts writability)

[bpow]

What problem did you meet?

I am working on an example helm chart to run logto on kubernetes (k8s). To reduce risks of privilege escalation many k8s clusters are configured to run in "rootless" containers, i.e., running as a non-zero uid (in some cases an arbitrarily-assigned uid-- for instance openshift clusters are set up this way).

I've already mapped /etc/logto/packages/core/connectors as a mounted directory so this running uid can make changes there.

I'm currently running into an issue with trying npm run cli -- db seed --swe because it copies alteration scripts into /etc/logto/packages/cli/alteration-scripts (so they have context of required dependencies). I can't even just mount that in k8s as a writable directory because the current code wants to remove that directory if it already exists (even if it is empty).

Describe what you'd like Logto to have

The ability to run from docker image in a "rootless" container as described above.

I may run into other issues as I work through this, but for the alteration-scripts, a few approaches that might address this:

• In the Dockerfile, chmod g+w /etc/logto/packages/cli, which would allow users with gid==0 to write to this directory (so the alteration-scripts handling could be handled with existing code-- it's pretty common in "rootless" containers for the running user to still be part of the root group, just not uid 0).
• Don't remove the /etc/logto/packages/cli/alteration-scripts directory if it exists, just remove its contents to replace with the desired current alteration scripts
• Figure out some other way to give the alteration scripts the desired context for dependencies? I'm not sure if it would work to make packages/cli/alteration-scripts to be a symlink to packages/schemas/alterations-js rather than go through the copying process that is currently in packages/cli/src/commands/database/alteration/utils.ts since the rootless uid would not be able to make this symlink in the runtime container. It also means there would have to be a mechanism for making this symlink or something like it in non-Docker environments.

I'll try a few of these to see which might actually work, but would welcome any ideas about which might be better.

This is related to #5961, of course.

[xiaoyijun]

Hi @bpow , I understand the issue you're facing with rootless containers. we'll find a better long-term solution, you could try modifying the Logto source code as a temporary fix.

The code that deletes the alteration-scripts folder is in packages/cli/src/commands/database/alteration/utils.ts

await fs.rm(localAlterationDirectory, { force: true, recursive: true });