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 <rjd4@ucs.cam.ac.uk>
Casper Dik <casper@fwi.uva.nl>
glenn@uniq.com.au (Glenn Satchell - Uniq Professional Services)
perryh@pluto.rain.com (Perry Hutchison)
Dave Fetrow <fetrow@biostat.washington.edu>
ian@sfu.ca
bern@kleopatra.Uni-Trier.DE (Jochen Bern)
Dan Stromberg - OAC-DCS <strombrg@hydra.acs.uci.edu>
Ian MacPhedran <Ian_MacPhedran@engr.usask.ca>
mikem@centerline.com
bwalker@antares.com (Brad Walker)
-----------------
Geoff Harrison
Opine Technologies, Inc.
geoffh@opine.com
-------------------------------------------------------------
From: Bob Dowling <rjd4@ucs.cam.ac.uk>
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,
rjd4@ucs.cam.ac.uk New Museums Site, Pembroke Street,
+44 223 334728 Cambridge, UK. CB2 3QG.
-------------------------------------------------------------
From: Casper Dik <casper@fwi.uva.nl>
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.
Casper
-------------------------------------------------------------
From: glenn@uniq.com.au (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.
regards,
--
Glenn Satchell glenn@uniq.com.au | "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: perryh@pluto.rain.com (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 <fetrow@biostat.washington.edu>
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: ian@sfu.ca
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: Ian_Reddy@sfu.ca
Academic Computing Services, AD1021 ian@sfu.ca
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 <strombrg@hydra.acs.uci.edu>
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.
Hmmm....
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 strombrg@uci.edu
-------------------------------------------------------------
From: Ian MacPhedran <Ian_MacPhedran@engr.usask.ca>
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: mikem@centerline.com
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
mikem@centerline.com
-------------------------------------------------------------
From: bwalker@antares.com (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