|From: Roland Bauerschmidt <rb@debian.org>
|Newsgroups: gmane.linux.debian.devel.general
|Subject: Re: [RFC] adding system users: which is the best way??
|Date: Mon, 1 Dec 2003 09:36:51 +0100
|
|Steve Greenland wrote:
|> If you're not going to re-use the ids (a good idea), then you might as
|> well leave a username associated with it, so that the admin identify
|> *why* it was used.
|>
|> My personal opinion and policy is that user ids should never be re-used.
|> I realize that on very large networks with many users (possibly
|> distributed timewise, like a univesity undergraduate system), this may
|> not be possible, but it ought to be true for at least the "system"
|> users.
|
|That's a good idea. I'll try to add that as an option to adduser.
|
|-- Roland

This is not yet implemented, but should be easy enough to build-

Greetings
Marc

After thinking more about it, the naive approach of simply looking for
the last used UID in the range to be used and taking the first one
after that one is bad since that uid could also have been used and
deleted again.

We'd need to use a persistent state file, which makes the change less
trivial.

Greetings
Marc

tags #248500 confirmed
thanks

Hello, on a local system I wanted to fix the problem talked about in
this bug, and for us, the "naive" approach of selecting a UID one higher
than the highest currently in the range was good enough. I locally
modified adduser on my system to do that, and I created a patch against
3.80 in case it would be at all useful.

The patch uses a "NO_REUSE_IDS" option, which activates the new behavior
if set to "yes". It implements the change in the "first_avail_id()"
routine.

I am curious about the state-file approach, though; if that is
introduced with a new version of adduser, what do you do about "holes"
in the passwd file that existed prior to installation of that new
version? Maybe do something similar to the naive approach once, to
pre-fill the state file?

Cheers,
Aaron

Hi Aaron

Thank you for the patch.

"NO_REUSE_IDS" sounds a bit strange, I'd rather call it "REUSE_IDS"
and set it to "yes" by default.

That would be the only feasible solution.

Jörg

Hast Du den applied? Ich find "reuse" nicht in der Konfigdatei und
auch nicht in adduser.

Grüße
Marc

Errm. That one was not meant to go to the BTS. I apologize.

Greetings
Marc

Hi

We need to have a persistent statefile if we want to avoid to reuse a uid
which was already used by some other user. Think of the following scenario:

adduser foo
-> foo gets uid X

deluser foo
-> uid X is no longer used

adduser bar
-> bar gets uid X

So this uid is reused, even with the "always increment the hightest
already used uid by one and assign it to the new user"-algorithm.


But the whole thing of making this value persistent seems rather ugly to
me. Need to think some time about that, maybe I have a better idea to solve
that issue (a file for a single value).

Joerg

Well, we already have this "state file" in the system, namely
"/etc/passwd". We could create a disabled system user with a system UID
(for example UID 999, and for example named "adduser"), which would be
managed by the adduser scripts, and which would hold in the GECOS field
the highest ever used user ID in the system.

So, every time a new user is added to the system, the adduser scripts
would update the GECOS field of this "adduser" system user.

This "adduser" user could be disabled ("passwd -l adduser") as it is
never meant to login into the system.

This solution keeps compatibility with the old scheme of things, and
needs no special state file, while solves the problem.

What do you think?

*UGH*

I'd prefer a /var/lib/adduser/state over abusing /etc/passwd any time.

Greetings
Marc

*UGH*

I'd prefer a /var/lib/adduser/state over abusing /etc/passwd any time.

Greetings
Marc