# Reuse UIDs and GIDs



## Nyx118 (Aug 7, 2021)

I am working on some ports that will run game servers that have custom rc daemons scripts are made to avoid the process running as root for some basic security. I read the handbook and get how to add them so that isnt a problem however I see that there is only 949 slots available (this ignores the already used slots).

My question is can/should I make one general UID/GIDs and then reuse it for each or make a separate one for each?
EX: Add a gameserver UID+GUID and anyone who ports a game server can use that id to run it.

I don't see an issue with them running as the same user and if someone doesn't want them to it's fairly easy to make a new account and edit the scripts to run under that new user. I know we aren't that close to filling up the UID/GIDs but I'm not a huge fan of using multiple slots since there is a limit and these slots could be used for other things.


----------



## mark_j (Aug 12, 2021)

I'm not sure where the 949 figure comes from.
I'm not sure also about your logic behind allocation of uid and gid, however if you're talking about the numbering available then you're mistaken about their size. They are at least able to support (2^32)-1 given their data type (__uid_t == uint32_t)

There may be provisos for this, for example NIS+ or even NFS, but you get the gist.


----------



## sko (Aug 12, 2021)

I suspect you want to delegate/rent/... those servers to various users/customers. Hence I'd HIGHLY recommend putting them in jails and NOT running those directly on the host! This way you also prevent messing up your UID/GIDs on the host.

Using jails would even highly simplify deployment and management of those game servers - just create a (or some) template jail(s) and clone every instance from that (->basejails). Upgrades only need to go to the template (or the release it was created from), new jails automagically have those updates and existing jails just need to be re-cloned.
Using something like iocell further simplifies those tasks and can be easily leveraged in custom wrapper scripts.


----------

