Add support for setting a custom uid:gid

[nickjj]

This will help folks who are running native Linux with a user/group that don't have a uid:gid of 1000:1000. This could be the case if they have multiple users on their system.

If you're using Docker Desktop on Windows or macOS or are running native Linux where your uid:gid is 1000:1000 then this won't affect you. Everything will work out of the box without having to customize anything.

I tested it by creating a different user on my system that had a uid:gid of 1002:1003. I set those values in the .env for both the UID and GID and things built successfully. I was also able to run everything without permission errors.

Testing instructions:

git clone https://github.com/nickjj/docker-flask-example helloflask
cd helloflask
git checkout feature-custom-uid-gid

cp .env.example .env

# [Uncomment and modfiy the UID/GID values in the .env file, you can search the file for it]

docker compose up --build

# Check things out at: https://localhost:8000 , you should see a page load with no errors in your terminal

Please comment in this PR that things worked successfully or post the error(s) if it didn't work.

I'm going to let this sit here until a few folks verify it works for them. I'm also going to use this time to see if there's a better way to do this. I don't really see too many other options. If anyone has any suggestions please let me know.

[nickjj]

Going to YOLO this one. I tested it on 2 systems and Docker Desktop.

[RuinedYourLife]

Hey there!

Quick review on this one
I have somewhat the same setup as you do on a dev box which doesn't use UID 1000 as a base. When I tried setting the current UID and GID like you did, my apt install would get stuck on processing triggers for libc. Looking a bit further, what I realized is my faillog and lastlog files (inside /var/lib/docker/...) would get very, very large. My dev box has 10 gigs of disk and it would get filled up all the way.
No error logs whatsoever, just getting a device is full after a while of it running.

What I realized is lastlog is indexed based on user UID. If you want to look for yourself, found this great stackexchange thread. So if like myself, you have huge UID's (i'm talking a few millions), well you're essentially "filling" up your disk with sparse files. The actual size of the file is much smaller and I don't really know a lot about how docker works it's magic, but I assume the snapshots created by docker take actual space on the filesystem (ext4 btw, maybe btrfs would fix that, not too sure).

Now, the --no-log-init should take care of this for the creation of the python user, I think? But with the node one, which was built first on my machine, it would just end up dying in a matter of a few minutes.

I don't know how one would go about fixing this, just tried giving a bit of informations with the lil amount of knowledge I have.

Have a nice day!

[nickjj]

Hi,

Thanks a lot for the extra insight. In your case did you have millions of users? Or is the issue here that I didn't encounter it because I once built that image with a UID of 1000 before I switched to a different 1002 user to build things?

If usermod doesn't support modifying that flag I suppose things could be adjusted to delete the node user and make a new one, although this sounds like the original node user being created should have this flag in the official Node image. Kind of feels like an oversight and maybe an issue should be open there to address that?

Edit: I ended up opening an issue at nodejs/docker-node#1779.

[RuinedYourLife]

You're welcome!
I don't have millions of users, I just happen to work on a dev box with randomly generated UID's that goes up to the millions (linked to id's we have on windows machines which have to be the same).

Having an UID of 1002 should cause no harm, the struct that holds the data is about 300 bytes. And since it's indexed based on UID, pam will seek to uid * sizeof(struct lastlog), so we're only looking at about 0.3MB. But with an UID of 900 millions (like in my case), we skyrocket to 270GB and beyond!

Great idea opening the issue!
I did not know about the hadolint warning either, could have spared me of some painful troubleshooting haha

[nickjj]

Ah, that makes full sense now.

The hadolint warning came up in this project's pipeline when I pushed the change without it: https://github.com/nickjj/docker-flask-example/actions/runs/3124229750/jobs/5067392851#step:4:16