Re: UID allocation policy [Re: automatic adduser/addgroup ...]
Raul Miller writes ("UID allocation policy [Re: automatic adduser/addgroup ...]"):
> The best compromise UID allocation policy, in my mind:
>
> (1) allow selection of lower bounds for each allocation group.
>
> (2) allow selection of upper bounds for each allocation group.
>
> (3) provide reasonable defaults.
>
> (4) when allocating, make sure that ID isn't already in use. Stop
> with error if no more available IDs in range.
Quite. However, there are some uids that cannot be allocated
dynamically - they need to be compiled into binaries and/or set in
tarfiles, &c.
We cannot check whether these uids are in use - we just have to
allocate a range for them that we claim, and anyone who uses these
uids for anything else will lose.
I think that we should confine these uids to as small and obscure a
(set of) range(s) as possible.
There is ample precedent for our allocation of 0-99 in this manner; we
certainly can't use from 100 to at least 32K for this purpose. I'd
therefore suggest that normal pqckages which only need 1 of these, and
then only rarely, use ones under 100 which come in the base package's
passwd file, and that packages which need many of them use ones over
(say) 65000 which don't appear in the standard passwd file.
*Both* types of package *must* check for their uids/gids in their
maintainer scripts, so that they'll work if those entries aren't
already present (creating them if necessary) and fail if they're used
for something else.
It seems to me that sensible defaults which break fewest things are to
have dynamically allocated system ids to go from 100-999, and
dynamically allocated ids for users to go from 1000-9999. 10000-59999
is by default reserved for any special purposes we can come up with
later (but we promise that they'll be dynamically allocated too).
...
> Given this partitioning of the work, the big issues become: what are
> reasonable defaults? Where should this be documented? (that is, to
> reduce the number of people affected by this issue to some kind of
> minimum).
I propose that we document this in the manpage for adduser and in
/etc/adduser.conf, given that adduser is implementing the policy as
set there and that that package contains the default policy.
When we have a separate admin guide for Debian systems it should go in
there.
Ian.
Reply to: