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

UID allocation policy [Re: automatic adduser/addgroup ...]



>>>>> "IJ" == Ian Jackson <ian@chiark.chu.cam.ac.uk> writes:

IJ> Lukas Nellen writes (SuperCite undone):
>> In many mixed environments, UIDs starting from 100 are used for
>> ordinary accounts. How do you prevent clashes? Wouldn't it be safer to
>> allocate UID's for system accounts starting from 65533 downwards? For
>> all I know, that is less likely to cause problems in an heterogeneous
>> network. 

IJ> The way you prevent clashes is by copying in a passwd file with the
IJ> uids you need allocated, or by reconfiguring adduser
IJ> (/etc/adduser.conf, I believe), before you install the packages which
IJ> make it allocate the uids.

IJ> Allocating system uids as high uids breaks the general assumption
IJ> which many old scripts (eg, arbitron) seem to use that system uids are
IJ> lower than user uids.

I don't see how this solves the problem. I'm thinking of the following
scenario: 
	Add a debian box to an existing workstation cluster. The UID's
for user accounts start from 100 (that seems to be rather
common). Some of those accounts are also in /etc/passwd of the debian
box. Now I add a debian package which uses dynamically allocated UID's
for the system accounts it needs. There is no way I can force them to
be below the user accounts already in use - and I cannot avoid to
break software which assumes that all system accounts have UID's lower
than those of user accounts.

I don't see how you can avoid this problem in an evolving system where
new user accounts and new system accounts get added. At least not if
you want to integrate your debian system with an existing installation
which starts allocating user UID's from 100 upward.

The possible solutions to this problems are (as far as I can see):
	Change the policy for the allocation of system UID's used by
debian. This also forces you to fix software like the script you
mention. But then, how does that script handle `nobody'? If it has
already has some mechanism to treat least this exception, couldn't
that be generalized? Or are the other, implicit assumptions about the
properties of `nobody'?
	Disallow the use of UID's for system accounts above 100 - this
will certainly break at some point because of overcrowding of the
region 0-100.
	Alternatively, forcing an existing installation to change the
UID's of it's existing accounts to accomodate some debian systems is
likely to meet the resitance of the administrators of the existing
installation. 

>From my point of view, it is important to be able to include debian
systems in a heterogeneous cluster of UN*X workstations without
requiring large changes to the existing installation. IMHO, this is
more important than trying to satisfy software that makes unwarranted
assumptions about the ordering of UID's. I believe that it is
important to get this right before the pending release of
1.1. Reallocating UID's later always requires a lot of care.

How do other people handle this problem? Or are most debian systems
either standalone or in debian-only clusters?

Sorry about being persistent - I hope I'm not just missing the point
in the current debian scheme.

			Cheers,
				Lukas
-------------------------------------------------------------------------------
   Dr. Lukas Nellen                 | Email: lukas@teorica0.ifisicacu.unam.mx
   Depto. de Fisica Teorica, IFUNAM |
   Apdo. Postal 20-364              | Tel.:  +52 5 622 5014 ext. 218
   01000 Mexico D.F., MEXICO        | Fax:   +52 5 622 5015


Reply to: