SUMMARY: beyond 60000 accounts

From: Geoff Harrison (
Date: Wed Jan 12 1994 - 08:40:09 CST

I asked whether it is possible to extend the limit of 60,002 user ids under
SunOS 4.x or 5.x.

The short answer is `no'. With source it should be possible but I don't
have source. Some suggested trying to spread the load between several
machines (not really an option for me). Others suggested duplicating
UIDs and playing games with GIDs and chroot(2).

The latter is probably the approach I'll take (hopefully without having
to fiddle with chroot(2)).

Many thanks to the following.

        Bob Dowling <>
        Casper Dik <> (Glenn Satchell - Uniq Professional Services) (Perry Hutchison)
        Dave Fetrow <>
        bern@kleopatra.Uni-Trier.DE (Jochen Bern)
        Dan Stromberg - OAC-DCS <>
        Ian MacPhedran <> (Brad Walker)

Geoff Harrison
Opine Technologies, Inc.

From: Bob Dowling <>

When I first started using Solaris 2, an individual at Sun (the guy
giving the training course I was on) mentioned that Sun were working on
a scheme they called "extended fundamental types". The idea was that
Sun could relatively easily (but still at a cost) build you a new Solaris
with (in this case) uid_t modified to allow for more users. Since then
the silence has been deafening. You might like to ask Sun Tech Support
what happened to EFT.

Bob Dowling: UNIX Support,
                                University of Cambridge Computing Service, New Museums Site, Pembroke Street,
+44 223 334728 Cambridge, UK. CB2 3QG.

From: Casper Dik <>

In SunOS 4.1.3, the answer is NO WAY. Uids are 16 bit.
In SunOS 5.3, the answer is: easy if you have the source.

None of these answers is particularly helpful. Just bugger Sun about this.

>(By the way, where does the 60,002 limit come from? Why not 60,000 or,
>more logically, 65,535?)

It is hard coded in the kernel. On places where uids are changed
(chown/setuid/seteuid) there is a simple check. All of Solaris 2.x
supports larger uids. I believe that this limitation was chosen to
prevent strange failure modes for people with machines that only
have 16 bit user-ids (the majority of hosts, I think).
Why they limited this to 60000 and not 65535, I don't know. That
arbitrary limit is actually hurting people who did have > 60000 account
numbers in SunOS 4.1.x.

There are a few ways to have this limitation fixed:
        - buy source (expensive, can't patch or upgrade easily)
        - bugger Sun to change then limit or make it configurable.


From: (Glenn Satchell - Uniq Professional Services)

I believe that it's a POSIX thingy. I don't know why it isn't 65,535
either. There is no way, with probnably any version of unix to get 300k
distinct uid's. Maybe if you split them over a couple of boxes and
repeated duplicate id's on each box. A bit of a hack but maybe the only
way to do it.


Glenn Satchell            | "This is a unix system.
Uniq Professional Services Pty Ltd  ACN 056 279 335  | I can do this easy."
PO Box 70, Paddington, NSW 2021, (Sydney) Australia  |
Phone 02 360 7434 Pager 016 287 000 Fax 02 331 2572  | - Lex, Jurassic Park
       "Sun Accredited System Consultants"           |

------------------------------------------------------------- From: (Perry Hutchison)

I'm pretty sure the userid has to fit in 16 bits. Increasing it to 32 bits "should" be fairly simple given source -- Sun Consulting could probably do it for you -- however this would make the filesystem incompatible.

You might look into SunOS CMW (B1-secure); it may have 32-bit userid's. However, being targeted at military applications -- who else would feel a need for B1 security? -- it is probably not inexpensive.

> where does the 60,002 limit come from? Why not 60,000 or, > more logically, 65,535?

65535 (== -1) is "nobody" and there may be a few more negative numbers either used or reserved for similar special identities. Also numbers from 0 up to something like 10 are built-in things like root, daemon, uucp, ...

Granted this explanation does not account for 5533 reserved numbers. I don't know what they are planning to do with the rest.

------------------------------------------------------------- From: Dave Fetrow <>

For what it's worth; a lot of machines have 32-bit UID/GID. I believe both Sequents` IPX and IBM's AIX are among them.

A problem that big might be one Sun would be willing to fix for you though. Who wants to annoy a customer with > 64,000 users?

-- -dave fetrow- ...a serf of the Lambda Calculus

------------------------------------------------------------- From:

Actually the limit *is* 64K in that an unsigned int is used for the uid. POSIX specification limit the uids to 60000 with 60001 reserved and 60002 for "nobody". The other five thousand or so seem to have been saved for something.

If you find a way to do more than 64K I be interested in a summary.

-- Ian Reddy, Systems Consultant E-mail: Academic Computing Services, AD1021 Simon Fraser University Telephone: (604) 291-3936 Burnaby, B.C. Canada V5A 1S6 Fax: (604) 291-4242

------------------------------------------------------------- From: bern@kleopatra.Uni-Trier.DE (Jochen Bern)

I suppose (but I'm not sure) that the Limit comes from the Number of available UIDs (64k minus those reserved for System Users or somesuch). In this Case, you should be able to get beyond the Limit by reusing UIDs (a *BAD* Idea (tm), but hey, it works at least ...)

I'm afraid that there's no Way to get beyond the Limit of 64k *real* Users because the UIDs have to fit into the Owner Fields of your File Systems, which would mean that you need a totally different OS. AFAIK, the 64k Size is fixed for everything called "Unix FS" ... :-(

Regards, J. Bern

------------------------------------------------------------- From: Dan Stromberg - OAC-DCS <>

If you need fully general accounts, you might be pretty stuck. There's an off chance you could get somewhere by installing an alternative set of login utilities - John Haugh's shadow password suite might be a good starting point. If sun's other binaries were compiled with sizeof(uid_t)==16, you'd probably still be stuck, unless you recompiled damn near everything. All but the most development'ish shops would be better off looking at other OS's.

Do all the accounts need to be fully general? If they can be relatively restricted, like don't need file ownership and could be contented with a few menu options, you could put multiple users on a single UID - much as a bbs system will often do.

Obviously, there may be some commercial package for sun that'll do this, but I'm aware of none.


Then again. Could you use multiple machines? Split the users across a handful of 'em?

Along the same lines, you might be able to use N distinct password databases somehow, by throwing in some chroot's, if you Must stay on a single machine.. You might set up a database mapping username->(chroot environment), hack a login/getty to read a username and switch to the right place, passing that username to the chroot'd env. Still a little complicated, and while it's a bit less graceful than the shadow thing above, it might take less time to implement.

Dan Stromberg - OAC/DCS

------------------------------------------------------------- From: Ian MacPhedran <>

No. The most uids that most Unixes can handle is 64K, and many can't handle more than 32K.

> (By the way, where does the 60,002 limit come from? Why not 60,000 or, > more logically, 65,535?)

It actually isn't 60002. The uids 0-99, and 60001 & 60002 are reserved for system accounts. The most users you can have is 60000 - 99 = 59901. (You may be able to put some in the 0-99 range, but you will have to be careful.) I am not sure why these numbers were used, but the uid is still represented by an (unsigned) 32 bit integer, so 64K would be the maximum.

The best solution I could think of would be to split "your" users into subdivisions based on the computers they access, and then assign uids based on treating each division as a separate set of users.

Ian. ---------------------------------------------------------------------------- Ian MacPhedran, Engineering Computer Centre, University of Saskatchewan. 2B13 Engineering Building, U. of S. Campus, Saskatoon, Sask., CANADA S7N 0W0 macphed@dvinci.USask.CA (306) 966-4832 Ian_MacPhedran@engr.USask.CA

------------------------------------------------------------- From:

You've run up against a fundamental limitation in the UNIX operating system. User numbers are represented with 16-bit integers (thus, even SunOS 4.x can only handle up to 65536 user numbers), and Solaris 5.x imposes an artificial limit of 60,000 on top of that actual, physical limit.

There is a kind of work-around, though. The important thing to take into account is that "60000" is how many unique user numbers you can have, not login names. Consider the following /etc/passwd lines:

bill::100:100:Bill User:/home100/bill:/bin/shell100 fred::100:101:Fred User:/home101/fred:/bin/shell101

Note that both "bill" and "fred" have the same user number - 100, but they can have different home directories, different groups, and different shells. Let me introduce the term "twin users" to refer to any pair of users who have the same user number, even though they might have different names, and so on. The obvious problem is that directory permissions are all handled at the user numbers, so twin users would have permission to access each other's files. [if this isn't a problem for your client, then you can stop reading here.]

If you need separate, protected home directories for each user, you might be able to get away with a fairly simple scheme, using group numbers to restrict users from seeing other, same-numbered user's home directories.

For example, as root:

mkdir /home100 /home101 chown root.100 /home100 chown root.101 /home101 chmod 550 /home100 /home101 mkdir /home100/bill mkdir /home101/fred

The permissions on /home100 and /home101 are r-xr-x---, so owner and group members can read and use these directories, but others can't. Bill can "cd" into the /home100 directory tree (which contains his home directory) since he's in group 100, but fred can't, since he's in group 101.

This is still somewhat ugly, since under this scheme, "ls -l" would show that Fred's files are owned by "bill" (in general, the first user is the "owner" when there are several users sharing the same user number). There are other complications with, for example, public directories, like /var/spool/mail. Bill and Fred would be able to read and write each other's mail files.

You can address this problem by using a more elaborate setup involving many copies of the root directory tree and using the "chroot" command (to put each user into complete directory sub-tree.) I won't kid you - setting this up would be rather tricky, and there are lots of subtle problems - for example, forwarding mail to the proper final location - that need to be addressed.

But I'd have to start billing for my time if I went into the design details of this scheme, and you may not want to get this complicated anyhow. If you have specific questions, drop me a line.

Mike Maciolek

------------------------------------------------------------- From: (Brad Walker)

Sun tech. support is wrong... The limit is 64K..

-brad w.

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:54 CDT