[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Dynamic user ID allocation policy question



On Fri, 5 Nov 1999 23:57:09 +0100, Wichert Akkerman <wichert@liacs.nl> wrote:
>Previously Zygo Blaxell wrote:
>>      1000-29999:
>>           Dynamically allocated user accounts. By default `adduser' will
>>           choose UIDs and GIDs for user accounts in this range, though
>>           `adduser.conf' may be used to modify this behavior.
>>
>> I think the phrase "dynamically allocated user accounts" describes exactly
>> what the 'foo' package does.  Unfortunately, I don't think this is the
>> intended meaning of this phrase as it appears in the Debian policy.
>
>Your case is pretty unique, 

Hmmm...I seem to be a master of getting myself into unique situations.
:-/ I've seen some experimental SSL-based certificate authentication
schemes that do dynamic local user account creation too, although they
tend to come with a database that suggests unique UID's too.  I guess
nobody has actually packaged any of these systems yet.

>We can't set a complete policy for people on how to allocate UIDs and
>GIDs since there are so many external factors we have no control over.
>You should never use UIDs and GIDs below 1000 since a system might use
>them, and this range should be big enough for all purposes. (I have yet
>to see a system with than 28999 users..)

With NIS, it's easy to get 30K user ID's into the NIS map, and therefore
onto each client system's uid address space as well.  I know of one
company with a single NIS database for all present Unix users in North
America--it used to be past _and_ present users, but they ran out of
uid_t bits.  The company employs about 80K people.

Of course, this company uses user ID's sparsely from 500 to 65500,
so it wouldn't interoperate with Debian policy anyway.  They also don't
allow machines running Linux to be connected to the same LANs as the NIS
servers, further reducing the usefulness of interoperation...

Here's what I propose to do:

1.  Make the package use 'adduser' to create the dynamic user ID's (name
and number are both dynamic).  This is arguably something it should do
anyway; right now I'm not sure how it generates these ID's, but I have
the sneaking suspicion it manipulates /etc/passwd directly...

2.  Document that 'adduser' should be configured properly if there is any
possibility of UID conflict.


Reply to: