github-starred/awesome-docker
2
0
Fork 0
mirror of https://github.com/veggiemonk/awesome-docker.git synced 2026-03-09 07:25:57 -05:00
Code Issues 5 Packages Projects Releases 1 Wiki Activity

[PR #989] [MERGED] Add userdef #1001

New Issue
Closed
opened 2025-11-06 12:12:40 -06:00 by GiteaMirror · 0 comments
GiteaMirror commented 2025-11-06 12:12:40 -06:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/veggiemonk/awesome-docker/pull/989
Author: @theAkito
Created: 4/1/2022
Status: ✅ Merged
Merged: 4/4/2022
Merged by: @agebhar1

Base: master ← Head: master

📝 Commits (3)

📊 Changes

1 file changed (+3 additions, -1 deletions)

View changed files

📝 README.md (+3 -1)

📄 Description

What userdef does

This tool is a more advanced adduser / useradd for your Alpine and BusyBox based Docker images.

For example, this tool may create a custom OS user with a custom ID inside pre-made Docker images, which perhaps already have a custom user defined and rebuilding the Docker image just to have your custom user in it is not an option.

https://github.com/theAkito/userdef#what

Why userdef exists

Reason 1

Now, more and more server apps try to go with the current meta of being available on Kubernetes, etc. This is a good idea, however it's often not well executed.
Almost all of the popular server apps are not cloud-native. Their structure is still of some legacy kind.
Examples are Mattermost, Gitea, Nextcloud.
These server apps have Helm Charts available. However, applying best practices, especially the ones regarding security are not easy to achieve.
Especially, when talking about the podSecurityContext. The fsGroup option is either not respected properly, which leads to broken deployments, or it's not even available and you have to add it yourself to the Helm Chart.

For example, take the Gitea Helm Chart as an example. You are allowed to set the podSecurityContext:
d94226765d/values.yaml (L19-L20)

But, if you provide your custom fsGroup value, then the deployment will be broken. Why?
66f2210fec/Dockerfile.rootless (L39-L48)

Because the user and group ID of 1000 is hard-coded into the Docker image.

Now, imagine you have an sshfs mount, which requires you using the user of the ID 9234.
The hard-coded 1000 inside the image breaks usage of this sshfs mount, just because it does not let you define a custom user with a custom ID.

To make all this work more smoothly, this tool aims to delete the existing user in that Docker image and then recreate it with your custom user, which has an ID defined by you, instead of being forced to use the randomly chosen hard-coded user ID.

Reason 2

You may just as well use this tool as a better adduser where the actual adduser or useradd (like the one in Alpine) have arbitrary and unnecessary restrictions, like for example limiting the UID/GID size to 256000.

https://github.com/theAkito/userdef#why

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/veggiemonk/awesome-docker/pull/989 **Author:** [@theAkito](https://github.com/theAkito) **Created:** 4/1/2022 **Status:** ✅ Merged **Merged:** 4/4/2022 **Merged by:** [@agebhar1](https://github.com/agebhar1) **Base:** `master` ← **Head:** `master` --- ### 📝 Commits (3) - [`6ebeafe`](https://github.com/veggiemonk/awesome-docker/commit/6ebeafed77e89bdb429f32aebe03533e65bc3e0a) Add userdef - [`a5d8cf9`](https://github.com/veggiemonk/awesome-docker/commit/a5d8cf9ded3645cb3625adf434c9854c8f23242d) Fix Developer Reference - [`6aa8d46`](https://github.com/veggiemonk/awesome-docker/commit/6aa8d46855b132804dc62238d6eb7676529008de) Fix Developer Reference ### 📊 Changes **1 file changed** (+3 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `README.md` (+3 -1) </details> ### 📄 Description ## What `userdef` does This tool is a more advanced `adduser` / `useradd` for your [Alpine](https://www.alpinelinux.org/) and [BusyBox](https://www.busybox.net/) based Docker images. For example, this tool may create a custom OS user with a custom ID inside pre-made Docker images, which perhaps already have a custom user defined and rebuilding the Docker image just to have your custom user in it is not an option. https://github.com/theAkito/userdef#what ## Why `userdef` exists ### Reason 1 Now, more and more server apps try to go with the current meta of being available on Kubernetes, etc. This is a good idea, however it's often not well executed. Almost all of the popular server apps are not cloud-native. Their structure is still of some legacy kind. Examples are [Mattermost](https://mattermost.com/), [Gitea](https://gitea.io/en-us/), [Nextcloud](https://nextcloud.com/). These server apps have Helm Charts available. However, applying best practices, especially the ones regarding security are not easy to achieve. Especially, when talking about the `podSecurityContext`. The `fsGroup` option is either not respected properly, which leads to broken deployments, or it's not even available and you have to add it yourself to the Helm Chart. For example, take the Gitea Helm Chart as an example. You are allowed to set the `podSecurityContext`: https://gitea.com/gitea/helm-chart/src/commit/d94226765d6e1f197a3112e1b1abbcd73a8bea33/values.yaml#L19-L20 But, if you provide your custom `fsGroup` value, then the deployment will be broken. Why? https://github.com/go-gitea/gitea/blob/66f2210feca0b50d305a46a203c2b3d2f4d3790b/Dockerfile.rootless#L39-L48 Because the user and group ID of `1000` is hard-coded into the Docker image. Now, imagine you have an `sshfs` mount, which requires you using the user of the ID `9234`. The hard-coded `1000` inside the image breaks usage of this `sshfs` mount, just because it does not let you define a custom user with a custom ID. To make all this work more smoothly, this tool aims to delete the existing user in that Docker image and then recreate it with *your* custom user, which has an ID defined by *you*, instead of being forced to use the randomly chosen hard-coded user ID. ### Reason 2 You may just as well use this tool as a better `adduser` where the actual `adduser` or `useradd` (like the one in [Alpine](https://www.alpinelinux.org/)) have arbitrary and unnecessary restrictions, like for example [limiting the UID/GID size to 256000](https://stackoverflow.com/q/41807026/7061105). https://github.com/theAkito/userdef#why --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2025-11-06 12:12:40 -06:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
broken-links
bug
cannot be evaluated
enhancement
health-report
help wanted
maintenance
pending-evaluation
pull-request
Mirrored from GitHub Pull Request
 question
team discussion
weekly-digest
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/awesome-docker#1001
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?