Dynamic user ID allocation policy question

[uwd38znr@umail.furryterror.org (Zygo Blaxell)]

Let's say I have a Debian package intended to be installed on Debian
systems and systems derived from Debian.  Let's call the package 'foo'.
The package name has been changed to protect the guilty.  ;-)

'foo' contains a user authentication utility which authenticates user
ID's using an external authentication database, and creates a new Unix
user account whenever a user first authenticates herself to the machine
that 'foo' runs on.  Both the Unix user name and corresponding numeric
user ID are dynamically generated, and any other resources associated with
that user (home directory, installed software, etc) are set up
automagically.

Depending on configuration, foo can behave in practice something like
Win95, where you just have to make up a new user name to create an
account on the machine, or like Athena, where you can walk up to any
machine on campus and log into it as if it was your own.

I'm consulting Debian policy and I don't see any numeric range that is
safe for the 'foo' package to allocate UID's from.  Policy does contain
the following ranges:

     100-999:
          Dynamically allocated system users and groups. Packages which
          need a user or group, but can have this user or group allocated
          dynamically and differently on each system, [...]

'foo' dynamically allocates accounts for "ordinary" users, not "system"
users, so I don't think this applies.  Plus in extreme cases I could see
a shortage of UID's occurring (consider a machine used by many people
for several years...although this could be mitigated by adding a garbage
collection mechanism to 'foo').

     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.

I believe the Debian policy is reserving this range for site
administrators to allocate accounts for users without risk of colliding
UID's with those used, required, or in this case generated by software.
When NIS or NFS appears on the horizons, one wants strict control over
which user ID's are allocated by a central authority that controls NIS
and which user ID's are allocated by anyone else; otherwise, NIS might
allocate a user ID that was previously allocated locally on some machine
by the 'foo' package.

Would a good solution be to suggest to people who must live with NIS
that /etc/adduser.conf should have one UID range for user accounts on
the NIS master and a different, non-overlapping range for user accounts
on the NIS clients?

     30000-59999:
          Reserved.

     65000-65533:
          Reserved.

Might it be possible to define some part of one of these reserved ranges
for dynamically allocated user accounts?

.