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

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

>>>>> "RM" == Raul Miller <rdm@tad.micro.umn.edu> writes:

  RM> The best compromise UID allocation policy, in my mind:
  RM> (1) allow selection of lower bounds for each allocation group.

  RM> (2) allow selection of upper bounds for each allocation group.

Since it seems to be impossible to come up with a general scheme that
satisfies everybody, I support that idea.

  RM> (3) provide reasonable defaults.

IMHO, the installation disks and the base system should provide the
defaults - maybe with an extra configuration screen when setting up
the base system (around the time when the networking is set up).

  RM> (4) when allocating, make sure that ID isn't already in use.  Stop
  RM> with error if no more available IDs in range.

The adduser script does that already.

  RM> Note that it's possible to have system IDs start at 1 yet climb to
  RM> 65000 if desired.

  RM> Given this partitioning of the work, the big issues become: what are
  RM> reasonable defaults?  Where should this be documented?  (that is, to
  RM> reduce the number of people affected by this issue to some kind of
  RM> minimum).

I believe that `reasonable' here is mainly a problem of legacy (maybe
a bit of aesthetics, too). On the one hand, we have the existing
debian installations. They use the current scheme, and any change
would inconvenience them. On the other hand, there are people who want
to integrate debian systems into an existing worksation cluster. In
that case, the policy for the allocation of UIDs is largely set by
whatever the cluster policy is. Very often, that means that user
accounts start at UID 101, leaving no room for dynamically allocated
system UIDs.

Trying to decide on an allocation scheme, there seem to be several
potentialy problematic aspects do deal with:
	Clusters which have non-linux members which use signed UIDs
and which might have difficulties with UID above 32767.
	Software which fixes UIDs at compilation time (e.g.,
qmail - if I understood the discussion about this correctly). This
kind of software can lead to nasty surprises if you reallocate UIDs on
you system and forget about such programs. 
	Software which assumes common habits as guaranteed, like that
system accounts have lower UIDs than user accounts. 
	Changing UIDs on a running system needs to be done
carefully. How carefully depends on the complexity of the setup -
think of a heterogeneous cluster running NIS+! And it requires to take
the whole system down. 

In some cases, using ugidd can solve mismatches - if all systems
involved speak this protocol. But as soon as you are using NIS or some
replacement, you have to have the same UIDs on all systems.

I suppose the documentation of the allocation scheme ought to be part
of the adduser package. After all, this package contains the
implementation of this scheme. If a decision has to be made during the
installation, a few lines should appear in the installation document
and/or on the relevant configuration screen.

What is the opinion of the maintainers of the base system and of the
adduser package about this issue? The issues discussed here would
probably affect their work. Is there any package around which actually
uses dynamically allocated UID's? The only time I have seen a
reference to them is for qmail - but is it already released as a
debian package? 

I apologize for insisting so much on that point, but I really believe
that the current scheme makes debian less of an open system than it
could be by making it more difficult than necessary to integrate
debian systems into existing workstation clusters. It would be good if
it were possible to resolve that point before the imminent release of
debian 1.1.

   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: