Re: Dynamic user ID allocation policy question
On Wed, Nov 03, 1999 at 08:06:51PM +0000, Zygo Blaxell wrote:
> 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?
1) There were some patches for kernel to use 32bit uids.(no used only heard)
So install them and use 100000-199999 or any other range other soft
doesnt even knows about.
2) If not, 1000-29999 should be a good range.
3) Consider using hurd. It has much more liberal uids policy.
Reply to: