Hi Juan, thanks for helping with adduser!
On Mon, Aug 31, 2026 at 01:46:38PM +0000, Juan Muñoz wrote:
The main issue I’m trying to address is the distinction between avoiding currently allocated UIDs and avoiding reuse of UIDs that have been allocated in the past. The latter requires some form of persistent state, since once an account is removed there is no longer an entry in /etc/passwd from which adduser can determine that the UID was previously used.
adduser has grown a state file in the past, it's a simple, persistent key-value store that could store the last UID being assigned by adduser and then just increment from there.
This leaves the use case when an account was explicitly created by the admin with a forced uid and then removed later, adduser will then happily reuse that uid when the counter reaches that value. I think we must ignore that since those operations could be done with useradd/userdel or by directly editing /etc/passwd without adduser knowing.
I’m therefore interested in investigating whether the existing UID pool mechanism could be extended or reused to implement the semantics requested by #248500, while considering a few questions:
I don't think that the pool mechanism is the right means to address this. pool is more a method to reserve uids, and adduser should actually avoid assigning uids/gids
1. How should UIDs assigned by adduser be persisted so that they remain unavailable after the corresponding account is removed?
See above, you can use a persistent counter.
2. What should happen when an account is recreated, should it receive its previous UID or should that UID remain permanently unavailable?
That uid is then lower than the counter and will not be reused.
3. How should existing systems be handled, where previously used UIDs are no longer present in /etc/passwd and therefore cannot be reconstructed reliably?
I think it would be sane to start the counter at FIRST_*_UID and then iterate until the first free uid is found. then initialize the counter and use that uid.
4. How should manually specified UIDs (--uid) interact with the mechanism?
The wish of the local admin wins and turns off the automatism.
5. Should system UIDs and regular user UIDs follow the same policy?
Yes, with dedicated counters.
6. How should concurrent adduser invocations be handled to avoid allocating the same UID?
That's a good point, is adduser not yet locking itself against concurrent execution?
Please let me know if any of those ideas are bad ideas.
Before starting an implementation, I’d like to check whether this approach matches the intended direction for #248500, and whether there are any previous proposals or design constraints I should take into account. If the bug is still considered open for development, I’d be happy to investigate this further and prepare a patch with tests. If, however, the issue has already been addressed by recent changes or is no longer considered relevant, I think the bug can be closed.
I would be happy if you'd work on that. This bug is the next I would have tackled myself, but I'll happily leave that for you.
Just remember rebasing your debian/latest branch on the main repo's before you branch.
Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
